iotivity-constrained
iotivity-constrained copied to clipboard
iotivity
Accessing multiple sensors unstable
This bug is based on PR 01org/SmartHome-Demo#150.
The BLE connection keeps dropping in <= 3 mins after it has been established via the command line using the instructions here: https://github.com/01org/zephyr.js/blob/master/docs/6lowpan-ble.md
While the connection is established, accessing more than 1 sensor in parallel via the REST API service will cause the micro controller to lock up.
@uhofemei The issue sounds like it might be related to the BLE stack configuration, or in any of the many other moving parts (hardware/drivers/Linux<->Zephyr BLE comms/…).
iotivity-constrained has been seen to capably handle many 10s of resources at once on Linux, and the Zephyr adaptation is very light.
Here is one thing you can try assuming you’re running a native server (and not Zephyr.js). While running the included sample server_zephyr on the tinyTILE board using BLE-IPSP, I’ve previously noticed that disabling the four options below in the included prj_bt.conf makes it run reliably.
#CONFIG_NEWLIB_LIBC=y #CONFIG_CONSOLE_HANDLER=y #CONFIG_EARLY_CONSOLE=y #CONFIG_STDOUT_CONSOLE=y
@kmaloor I was hoping to venture beyond trying to resolve this using config options. I agree with you there are many moving parts in the stack, and I wouldn't be surprised if there is more than one issue that needs to be resolved. More in-depth investigation and a better bug report outlining where the issues lie is needed.
@uhofemei Understood. But the very fact that altering the OS configuration apparently mitigates the problem indicates that it is close enough to underlying cause (like may be some error condition in the network stack/driver isn’t being handled gracefully). Suggest that you escalate this to the Zephyr folks to find a more permanent fix, or to even just to understand how to gather more useful debugging info from the network stack.
I will try out the options using the multi-server native code implementation. If things don't improve, I can file a bug report against the Bluetooth driver, but it won't say much more other than "it doesn't work."
@uhofemei Frankly, I’m not really sure about what I can add here :-) Ideally, the engineer(s) who worked on the app should be involved in this discussion so they can quickly address any feedback/suggestions from the Zephyr team.
At this time, all I’d say is if for eg. you’re seeing that allocating more buffers in the BT stack consistently makes the app run longer, then that's the sort of thing that the Zephyr team should know so they can make suggestions.
On re-reading your initial message above: “… accessing more than 1 sensor in parallel …” I wonder if you could ascertain that it's a networking glitch, or, something to do with many GPIO (or whichever h/w interface) reads at once. If you could use just one sensor and increase the frequency of requests, do you see the locking up behavior? Things like that.
@uhofemei Here are a couple of things that you can quickly try: In the native sample app, comment out those 4 options I indicated in my message above in its prj*.conf if it's currently enabled, and then test.
If you still see a lock up, then try commenting out the sensor/GPIO reads in the app, and instead plug in fake values in its handlers so they respond with something, and then test. This way you can eliminate that as a potential cause.
@kmaloor I checked and the config options you highlighted are disabled in my build. James was saying he added the following two options, which improved the general stability quite a bit. https://github.com/01org/zephyr.js/pull/1250/commits/d94c84b43a4e896fd8aec77abb79d8651ede66fd