Accessing multiple sensors unstable

[ghost]

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.

[kmaloor]

@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

[ghost]

@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.

[kmaloor]

@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.

[ghost]

Would you be able to help reporting it?

[kmaloor]

@uhofemei
Sure, if you want to draft something, I can comment on it.

[ghost]

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."

[kmaloor]

@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.

[ghost]

When are you going to be back in the office to talk about it? :)

[kmaloor]

@uhofemei
Let's chat tomorrow.

[kmaloor]

@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.

[ghost]

@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.
intel/zephyr.js@d94c84b