Answer

The reason for two route tables is a combination of things. The first stems back to when our NCP were tight on RAM. For that reason, we had to use the host to hold the routes. However, the NCP needed routes for certain messages in order to answer them without needed to talk to the host (i.e. ZDO messages and Join/Rejoin Requests). Now we use it because it allows us to not need to talk to the host for some messages, but also because it is easier to keep the past architecture intact. So in the case of the SoC we only have one route table.

The way it works is that a message comes in to the NCP. The NCP either handles it with or without notifying the host. If it does not notify the host, and the host had not previously setup a source route (using ezspSetSourceRoute()), the NCP will send out a response with its own source route. If it notifies the host, the host has a chance to provide a source route with ezspSetSourceRoute(). If it does not, the NCP will handle it with its own source route, and it will use its own source route for the response. This means that you can set up a larger route table on the host and not be too worried about having too small of a route table on the NCP. This does not mean we recommend putting a small route table on the NCP, but if you need the space you can.

Currently, the best practice recommendation is to put all the source route table data on the NCP (if there is enough RAM on the NCP). Then you would only want to use a host-side source route table if you expected to talk to more nodes than your NCP-based source route table could hold. Currently, 254 source routes is the maximum that the NCP's RAM can have. Part of the reason why this is best practice is because it allows the NCP to respond to messages without having to ask the host for a source route, thus increasing the speed in which it can respond.

When using a High RAM Concentrator it is also important to keep atleast a few source route table entries on the NCP. If you don't it is possible to hit a condition where a node sends a ZDO request to the concentrator and does not provide a Route Record and then the concentrator does not have a cached source route on the NCP. This puts the concentrator in a situation where it is unable to respond, and the ZDO does not go out. This will force the sender to send a retry and possibly initiate a network address discovery. At this point if a source route is not intact the network address discovery would not be responded to.

Answer

This knowledge based article will help you get your application setup with multi-network capability. If you are interested in details about what multi-networking is, please read up on the document documentation/ApplicationNotes/AN724_Multinetwork.

For instance, here is an excerpt from the document:

"A multi-network device may operate on either two different SE networks or on an HA network and an SE network. Beginning with EmberZNet 5.3, a multi-network device may also operate on two different HA networks. In a multi-network configuration, the device must join at least one network as a sleepy end device. It may act as a coordinator, router, end device, or sleepy end device on the other network. HA and SE are the only supported security types. ZLL devices are not supported."

Another stipulations about multi-networking to be aware of is that multi-networking is stripped out of EM2xx and EM351 platforms in order to save flash.

1. The first thing you need to do is add a second network in the General Tab >> Network Configuration field.
2. Once you do that, App Builder will allow you to go into ZCL Clusters Tab >> Multiple endpoint configuration field to create a new endpoint that uses a different network.
3. After creating a second endpoint, in the endpoint field go to the "Network" and select the second network.
4. Finally, in the Znet Stack Tab >> Network Configuration field you can setup your second network device type and security.

One of the advantages of using our framework when using multi-networking is that all of the plugins have been modified to natively support multi-networking.

When starting with multi-networking, it may be benificial to investigate the emberAfPushXXXNetworkIndex functions described in app/framework/include/af.h as well as functions containing “NetworkIndex” in the name. These functions are useful APIs when dealing with multi-network operations.

Answer

The first thing to do when setting you custom manufacturing tokens depends on whether or not you want to use a custom token header file. It does not matter if you choose to use a custom header file, or if you modify the generated token header file as it will be the only one used in the project. However, if you do decide to use your own custom header file you must define APPLICATION_MFG_TOKEN_HEADER to be your custom header file in your IAR preprocessor. When creating a custom token header file, token.h has helpful instructions. It is also important not to use inclusion guards (#ifndef/#define) in your application header files as the token reference scheme will not work with them. (If you are adding the define to App Builder, make sure to select the -D option).

Please note that if you do decide to modify the generated file you will need to be very careful not to overwrite it once modified. The main concern of it being overwritten is when you regenerate your project. At that point it will, by default, have the tokens file selected as being overwritten. Make sure to deselect it any time if you have made edits to the file that you want to keep.

General token definition found in token.h:
* The most general format of a token definition is:
*
*