Retaining paring when power cycled

Hi John,

SimpliciTI does not have such a feature. An enddevice that is reseted could send a broadcast and every device checks its connection table if a link was established upon receiving the broadcast and starts the unlink/link process.

The alternative would be to save the connection table in a persistant memory before the reset. The name of the connection table is sPersistInfo.

Is there example code for either of these solutions?

Please send me information on how to save / restore the information on the CC1110 devices.

I dont know how you can save data in flash during runtime because I dont have any experience with 8051 MCU, but basically you just have to save the content of the sPersistInfo struct in flash. Then you reset the device and overwrite the content of this struct in the RAM with the data in flash after you called smpl_init, because this call resets this structure.

I have never implemented both suggestions, so there might be side-effects, at least for the second suggestion.

You could also ask Hunter Wang for assistance, because I think that he successfully implemented it ([url]http://e2e.ti.com/support/low_power_rf/f/156/t/147320.aspx[/url]).

What's the relationship between sPersistInfo and NVOBJECT?  I can enable NVOBJECT_SUPPORT in nwk_config.dat, which says "Adds support for gerting and setting connection context for saving across resets."

IOCTL_OBJ_NVOBJ

Non-volatile memory object

Get and set the NV object. This permits a device to save connection context across power cycles so that communications can be restored in event of a reset.

Are these different ways to do the same thing?

This function gives you only a pointer to the sPersistInfo structure nothing more.

Hello.

mark sonn

This function gives you only a pointer to the sPersistInfo structure nothing more

It's enough.

The ioctl call gives you what you need. You get a pointer to the NV object and the length of the object. You need to write your own flash driver and save the context described in the ioctl call. On power-up use the same call to find out where to put the saved information. It is up to you to manage the saved area in your flash. It is not intended that you directly manipulate the NV object. That is why there isn't any information about the object in the API document. You of course are free to mess things up on your own...

You have another burden as well. Though the binding of Link ID to connection information is established by the NWK layer during the link transaction it is up to the user application to maintain the semantics of the connection. That means if you save the NV object, which contains connection information, you also need to save your application's Link ID map. It's your application that knows what Link ID belongs to what connection. In the case of an ED where there is likely only 1 connection and it is to the AP it is still good practice is to save the Link ID map. Though the Link ID is usually 1 for EDs in a single connection to an AP this is not guaranteed anywhere.

Hope this helps.

lfriedman

Yes, I'm going to need to store some other link-related variables, too, but that's very helpful, thanks.

Aren't the linkIDs listed in sPersistInfo.connStruct[i].thisLinkID, though?

Is the NVOBJECT size a fixed number?  Determined by fixed things like NUM_CONNECTIONS, maybe?  If not, is it possible to calculate the max size for a given compiled program?  I might want to do some kind of wear-leveling.

Hello.

Jonathan9420

Aren't the linkIDs listed in sPersistInfo.connStruct[i].thisLinkID, though?

Yes but as I mentioned only the application knows the context. Though one could peruse the structure for Link IDs, without context this would be pretty useless if there were more than a single connection. It's a better design to keep the context where it has meaning -- at the application. The Link ID is intended as a handle at the application layer where it has a context (the link transaction) not at the NWK layer where it is side effect.

Jonathan9420

Is the NVOBJECT size a fixed number?

Yes the size is fixed for a given compiled and instantiated image. Its size is not dynamic at run time.

Jonathan9420

I might want to do some kind of wear-leveling.

I don't recall the specifics of the MCU you are using but it might be a challenge in the 8051 Harvard architecture with relatively large page sizes and relatively small erase duty cycles...good luck!

lfriedman