This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2538: ZStack 3.0 and AN123 Breaking the 400-Node Barrier

Part Number: CC2538
Other Parts Discussed in Thread: Z-STACK, , CC2592

AN123 published in 2014 predates ZStack 3.0 and Z3.0 raises some memory issues around Key storage for large 400+ Z3.0 networks

In the ZStack 3.0 Developers Guide

S 10.6.3 "Z-Stack Security Considerations", S 10.6.3.1 "For TC Devices" Reads:
"...This limits the number of devices in the network to the number of entries that the TC can have."... and "...This optimization allows a Z3.0 TC device to have up to ZDSECMGR_TC_DEVICE_MAX Z3.0 devices in the network..."

For the cc2538 the ZDSECMGR_TC_DEVICE_MAX define in ZDSECMGR.h is '40' (Z3.0 devices).

If my understanding is correct the subsequent preprocessor test of the number of NV entries yields a max of 238, (ZCD_NV_TCLK_TABLE_END - ZCD_NV_TCLK_TABLE_START) and this TCLK Link Key table is followed sequentially in NV number range by the APS Link Key Table (ZComDef.h).

Does TI offer any further guidance to achieving the AN123 Breaking the 400 Node Barrier in light of ZStack 3.0 for a network of solely Z3.0 devices?

Ideally guidance additional to the source code comment of extending the range of TCLK IDs, i.e. is it best to use a new number NV TCLK range or bump all the subsequent NV number ranges higher?

Also regarding the developers guide info in 10.6.3.2 "For Joining Devices", the joining Jitter. How to effectively implement a jitter routine for factory new ZC3.0 devices joining at the same time presumably so as to avoid simultaneously filling the Install Code Key NV scratchpad space ZCD_NV_APS_LINK_KEY_DATA_START (to ZCD_NV_APS..._END) and stall or lose joining requests?

The 2014 AN123 also mentions the need for joining jitter it's S 3 "Test Application", a range of 60secs prevent traffic congestion - is this still sufficient for ZC3.0?

Also how to safely extend the size of the HAL_NV_PAGE_CNT from the default of 6 (hal_board_cfg.h) to accommodate the additional Z3.0 TCLK entries of APSME_TCLKDevEntry_t (APSMEDE.h, size 12 bytes each) i.e. will the CC2538's dual OTA image memory ranges or other code be impacted perhaps requiring manual changing of defined memory spaces?

Also will a joining Jitter alone be sufficient or should I also expand the APS Link Key NV number range and storage allocation for a 400+ node network?

Are there other items I need to consider for a ZC3.0 400+ node network implementation especially as I can't test it until after mass production (and installation)?

Thanks in advance.

  • HI Roz,

    For starters, can you provide some more information about your application? What types of devices will you be using in your network primarily (ZR/ZED)? What will the network topology look like in the end?
  • Hi Jason,
    Thanks for replying.

    For ease of field deployment and replacement its planned for the devices "out of the box" to be ZR Routers (aside from the ZC coordinators/gateways/concentrators) in an MTO routing scheme.

    The devices are mains powered so power consumption and sleep mode are not functional issues (CC2538 with CC2592).

    The physical location of the ZC within the network will be opportunistic depending upon internet availability, that is it may be central or towards one end or side of the physical area covered by the nodes.

    The nodes will be performing a mix of data acquisition and control.

    The nodes will have OTA updates enabling network optimisation after deployment should topology issues be encountered with a particular physical deployment (i.e. reduce RF TX Power, change some nodes from ZR to ZED etc).

  • Hi Roz,

    Very interesting question you have here. I will try to elaborate in each item/question.

    The Nv items defined in ZComDef.h can be redefined by the user of the stack to fit its purposes, you can freely change the ID index of the entries to whatever you need or you can use the application side of the Nv Index to increase the TCLK  (application index goes from 0x0400 to 0x0FFF), index beyond 0x1000 seems to be used by the Nv driver. If you were planning to use all those Ids of the application, you can use the ones that the TCLK was using. Just be aware when updating to later releases of the stack, because thoase are likely to have those Ids sorted in the same way.

    Consider that all the keys in the stack have certain data such as in/out frame counters in RAM to optimize its usage and to not perform lots of Nv operations (read/write), so is expected that if you increase the number of TCLK you will also require more RAM by sizeof(APSME_TCLinkKeyFrmCntr_t) per entry, for which if you exceed the RAM usage you can modify the linker file to enable the additional 16K of RAM in the CC2538 by changing:

    define region SRAM = mem:[from 0x20004000 to 0x20007FFF];    

    to

    define region SRAM = mem:[from 0x20000000 to 0x20007FFF];  

    This RAM is by default disable because it is not retained in the sleep modes, but if you will use it in a coordinator, then there should not be any problem.

    The linker file you have to modify for this will depend on which option for upgrading the coordinator you will want to have. Coordinators usually use the Serial Boot Loader for upgrading instead of the OTA, at the same time that this device is the server for the OTA, in this case you will have to modify cc2538-sb.icf, for which you can increase the Nv memory region by reducing the lower bound (0x0027C800) accordingly to the number of entries you are adding (12 bytes per entry).  Also make sure to increase the range of this region by multiples of 2k and update the HAL_NV_PAGE_CNT accordingly.

    If you want to have OTA upgrade in coordinator, then you will have to map the regions used in cc2538-OTA-A.icf to see if there is any continuous memory in which you can fit the pages you need (6 + the memory required for your additional devices), if there is no section in which you can fit this, then you will have to compact the regions used by the OTA and do the changes in the OTA code.

    Nv memory region:

    define region NV_MEM = mem:[from 0x0027C800 to 0x0027F7FF];

    Install codes are a way to avoid using the default key during the joining process and it is not the default mechanism or a mandatory mechanism to join Z3.0 devices to Z3.0 networks, but it is a way to add an additional level of security during the joining process as each Install Code is unique per joining device, in that sense it is not related to the congestion that the network can have during the joining process, still, you must be aware that the coordinator only supports 13 install codes at the same time, which means that you can register 13 devices and no more install codes can be added to the coordinator until any of those devices join the network. Upon joining those devices will perform the TCLK exchange and will update its key from IC key to Unique Key and IC entries will be released for other devices to join. You can modify how many IC entries to support by increasing the size of the table defined by ZCD_NV_TCLK_IC_TABLE_START and ZCD_NV_TCLK_IC_TABLE_END.

    Regarding the jitter for joining devices, each device joining must perform an update of its APS key which consist of the exchange of several packets, attached is a capture log of a single router device joining which takes ~1.5 seconds to complete its joining, From discovery the network (beacon request) to finish the key exchange (APS confirm key). Even when the stack supports multiple devices joining by listing those in a queue to perform this key update, it is not advice to perform the joining of more than 3 devices at the same time for large networks as the channel can be too noisy at later stages (devices sending link status, joining devices may be several hops away of the coordinator, joining devices may be retrying several times any of the joining step or the TCLK exchange procedure). 60 seconds are definitely not enough for Z3.0 devices and an increased jitter must be used (some testings will need to be done to tune this as it may vary considerably by the topology of the network, as direct joining are faster than joining hops away of the coordinator), also turning devices by sections could help to facilitate the joining process.

    Make sure that for your network NWK_ALL_FRESH is set to false, as this flag enables the validation of the nwk frame counter for all incoming frames, and in massive networks such as this is likely that not all the devices will have space to store all the devices from which they can receive (or forward) frames, and that will result into frames not being process or forwarded. EDITED: This flag only affects frames received by the next hop, so as long you receive the frames from neighbors and you can authenticate them its all good regardless of the size of the network, so it should be safe to leave this as TRUE.

    If your network will consist of your devices only and will not interoperate with other devices, you can reduce the period at which your devices send link status command to reduce the OTA traffic, but make sure that all the devices does have the same period, otherwise the routing mechanism may not work properly. The period is defined by NWK_LINK_STATUS_PERIOD.

    Use APS ACKs and foundation default responses only when needed by the applications as this can easily spam the network unnecessarily, as well as the discovery/commissioning process (Finding and Binding or searching for the OTA server).

    Note: The APS key used for the capture log is in the top right of the picture.

    Hope this helps!

     Capture log of Z3.0 joining.zip

  • Hi Luis,

    Thank you for the excellent information.

    I look forward to applying it in the coming weeks when our development reaches the appropriate stage.

    Of note we have selected the 32k ram CC2538 devices for our project and the additional ZC3.0 install code security is a beneficial feature we intend to utilise in our application.

    I'll let you know how we get on in our testing.

    Kind Regards,

    Roz

  • Even this Question has been answered,I want to say something yet.

    I guess you has the two question:

    1、More than 400+ Node Barrier in light of ZStack 3.0

    As you see AN123 pdf documents,swra427c.pdf, The SRAM size is the restrictions deploy more than 400+ nodes in the network,i don't understand TI design the CC2538 within SRAM is 32Kb,but not 32M byte.I don't think the 32M byte SRAM will cause the cost rasing more.

    2、TCLK(Trust Center Link Key) difference be stored in NV Z2.6.x and Z3.0

    As the other e2e Community Member mention, Z3.0 will release the TC NV entries if the device exchange TCLK(joining the network formed by coordinator),of course,you be permit building all device(ZR or ZED) with the same TCLK;

    Note:
    the install code(TCLK with IEEE address) is the specific feature in Z3.0 issue.
  • Hi Luis,

    Setting the SRAM region to start at 0x20000000 causes execution failure on startup for the "OTAClient-ImageA - with Bootloader" (based on the simple switch). The debugger can't reach main() and a power cycle to boot the CC2538 and the firmware still fails to run.

    The lowest the firmware will run is at 0x20002000 thereby losing 8k ram. I can't see anything in the memory map to explain this behaviour.

    I also tried placing "theHeap" array down there by creating another memory region at 0x20000000 and keeping SRAM at 0x20002000 (confirmed in the map file) however the same failure to run occurred. Any thoughts as to why?

    Additionally I checked the "Image Boot Manager" OTA bootloader's memory map and it's SRAM was set to 0x20004000. Changing it's SRAM to 0x20000000 doesn't seem to cause issues but I haven't tried any OTA updates yet in this configuration.

    Thanks in advance,
    -Roz
  • Hi hold li,

    Sorry for the late response,

    Regarding question 1, I would suggest to contact TI directly if you have questions on the roadmap for their devices.

    For question 2, I am not quite sure to understand what you are referring to, can you elaborate a little bit more on your question?

  • Hi Roz,

    Currently I am unavailable to perform any test, probably next week I will be able to do so and then I could help with this.
    Let me know if you have any findings in the meantime.