Hello forum!
I need to rebuild a ED-ED link after a power failure in any of the two EDs.
For this purpose I store the serial number of the peer, which I get using nwk_getConnInfo.
When starting up I check the serial number field and call SMPL_Commission with the stored SN.
The other ED is sending data once a second, is not reset(!) and continues with the communication after the SMPL_Commission in the restarted ED.
But this only works, when I use the same port numbers that were assigned when the link was created. In my example the portRX is 0x20 (= PORT_BASE_NUMBER) and the portTX is 0x3D (= SMPL_PORT_STATIC_MAX - 1).
In the SMPL_Commission call the locPort parameter has to be 0x20 and the rmtPort parameter has to be 0x3D for the link to be rebuild after a reset, which required a modification of the port sanity checks in the SMPL_Commission function.
I found some examples in this forum that suggested a value of 0x3E for both ports in the SMPL_Commission call, but since these values don't work for me, I would like to ask:
- How are the port numbers assigned during the initial link? Are the values 0x20 and 0x3D OK? According to the SimpliciTI spec they are available for "User handlers", but can I be sure that these port numbers will always have the same value?
- Why is the sanity check in SMPL_Commission made the way it is? In one post I found the advice to increase PORT_USER_STATIC_NUM to a value of 2, this would allow a commission using port 0x3D, but still fail on 0x20.
Thanks in advance for any help on this issue.
Jörn
Hello.
JPeWhen starting up I check the serial number field and call SMPL_Commission with the stored SN.
You should not use this API to restore a connection that was originally established using the Link/LinkListen transaction. The proper way to restore a connection originally eastrblished with the Link/LinkListen trasnation is to save and restore the connection context using the non-volatile object support.
JPe- How are the port numbers assigned during the initial link?
The mechanism is straightforward but too involved to explain here. You can read the code comments -- you might be able to figure it out. But these assignments are purposely hidden from users. They are NWK layer objects and users should not mess with them.
JPe- Why is the sanity check in SMPL_Commission made the way it is?
If you use the SMPL_Commission() API you need to assign port numbers. In order to prevent user assinged port numbers from interfering with the NWK layer mechanism for assigning ports the port namespace is partioned into two subsets: the portion used by the NWK layer and the portion available for users to assign directly using the SMPL_Commission() API, the static portion. Because these subsets are distinct the SMPL_Commission() API does a sanity check on the range of the port arguments. The size of the static portion is adjustable by setting the PORT_USER_STATIC_NUM macro to the desired number of static connections you will be creating.
As I mentioned earlier, to restore a connection in the manner you describe use the NV object support. The SMPL_Commission() API is not intented to be used for this purpose. It is intended to be used to set up connections between peers that are "hard wired" and known beforehand. Its use is symmetrical: it must be used on both peers. If both peers used SMPL_Commission() originally then you can use it when restoring power. But as I mentioned before you cannot mix usage so shouldn't use SMPL_Commission() to restore a connection that wasn't originally set up using that API. If you hack the code to get around this you will get what you deserve :-).
lfriedman
Hello lfriedman,
thank you very much for your comments and explanations.
However, there are still some questions left.
lfriedman As I mentioned earlier, to restore a connection in the manner you describe use the NV object support.
As I mentioned earlier, to restore a connection in the manner you describe use the NV object support.
Yes, that would be the alternative - playing by the rules ;-)
But since I have to support connections to up to 32 devices in one ED, I was looking for a method to reduce the needed space in non volatile memory and using SMPL_Commission (with fixed port numbers) would only require storage of the serial numbers.
lfriedman The SMPL_Commission() API is not intented to be used for this purpose. It is intended to be used to set up connections between peers that are "hard wired" and known beforehand.
The SMPL_Commission() API is not intented to be used for this purpose. It is intended to be used to set up connections between peers that are "hard wired" and known beforehand.
What's the big difference between "hard wiring" the serial numbers beforehand and obtaining them (once) through an initial Link/LinkListen and them storing them? This should still work as long as you have only a single link from peer to peer and don't attempt to link after commissioning.
lfriedman Its use is symmetrical: it must be used on both peers. If both peers used SMPL_Commission() originally then you can use it when restoring power.
Its use is symmetrical: it must be used on both peers. If both peers used SMPL_Commission() originally then you can use it when restoring power.
If both peers restart, then they both will be commissioning (if linked before power failure). But a power failure can occurr on any of the two devices at any time, so I also have to re-eastablish the connection from only one peer.
lfriedman But as I mentioned before you cannot mix usage so shouldn't use SMPL_Commission() to restore a connection that wasn't originally set up using that API. If you hack the code to get around this you will get what you deserve :-).
But as I mentioned before you cannot mix usage so shouldn't use SMPL_Commission() to restore a connection that wasn't originally set up using that API. If you hack the code to get around this you will get what you deserve :-).
Well, I'm very happy with what I got so far ;-)
But the reason for my happiness could well be, that I can't see the evil that lurks ahead of me :-D
Kind regards,
JPeBut since I have to support connections to up to 32 devices in one ED, I was looking for a method to reduce the needed space in non volatile memory and using SMPL_Commission (with fixed port numbers) would only require storage of the serial numbers
This scenario (or one like it) appears to be a common one: the need to support a large number of devices in a star configuration. I suppose I should have created a sample application dealing with this. I have proposed a solution to this in previous posts. I'm too lazy to find the threads and I'm also apparently too lazy to post a White Paper or App Note. (Besides, I retired from TI so my day-to-day contact with issues is diminished.)
But I digress. Here is a suggestion.
The idea here is to commnicate with datagrams only with no formal connections established. Since the messaging between peers is not connection based you will have to demultiplex the received messages based on the message token. You won't have the Link ID to identify the individual peers. Link IDs and ports are of no concern. In addition, any further discipline normally handled by a formal connection will now have to be done in the application. Also, since these are essentially an application layer broadcast messages everyone gets them so everyone will have to be prepared to deal with this case.
On the other hand, using non-connection based messaging might prove more flexibale and more efficient from a resource perspective. Assuming you have a star configuration the end points (EDs) may not need to store any information about its peer (hub). The hub may only need to store the indentifying token of each ED peer device. Any other embellishments would be realized by your own (presumably simple) application layer protocol.
As I noted in some previous thread there is a public symbol not part of the SimpliciTI API nwk_globals.c:nwk_getMyAddress() that provides access to a device's address. The EDs can use this symbol to get the token to include in each message for identification. If you can restrict your devices to known address ranges you could shorten the number of bytes you'd need to send as an identifying token...kind of like a subnet mask. You get the idea.
Maybe this will help. This is just a suggestion and an outline of what you might try. It's a little more involved and it may not be what you need. But I leave the remainder as an exercise for the reader. Just like school.