...
- Join a network: Most samples are written to explain a concept without having the mote join a network. Always test your application with the mote joined to a network - this can catch race conditions between the stack and app that might otherwise be missed.
- Test response codes: Your code should always look at responses to OCSDK functions - some non-zero (!= DN_ERR_NONE or DN_API_RC_OK) responses provide actionable information that can be used instead of asserting, e.g. if a device is already open, or the mote is in a state where the command is not valid.
- Get busy: By default the embedded manager can handle data published every 9s in a 100-mote network - normally you should be using services if you intend to publish faster than that. Try publishing every 5s to see what your application does in the event of a packet being rejected by the stack. You can also add a dummy higher-priority task that keeps your other tasks waiting to check for thread priority problems.
- Check your buffers: If you have the possibility of variable size messages or device commands, make sure you test with the maximum message sizes to avoid buffer overruns.
- Watch your tasks: the
mshow stacksCLI command is available to check stack memory usage. If you're getting close to 100% on one of your application's tasks, you should increase its allocation inapp_task_cfg.h.
...