Jira 906 Device locks up using CurieIMU

[khanning]

While testing the new 2.0.0/2.0.1 corelibs I have encountered a bug using the Curie IMU module. With the 101 in peripheral mode, if a BLE characteristic is written to from an external central device while using the IMU, the device will occasionally lock up requiring a reset.

I put together a simple test case by modifying the led example sketch to read from the IMU periodically. You can use the included ledtest.js node script to communicate with the Arduino.

led.ino
ledtest.js

To test:

1. Upload the led.ino to the Arduino 101 using either 2.0.0 or 2.0.1 corelibs
2. Run npm install noble in the same directory as the ledtest.js file
3. Execute node ledtest.js and wait for the device to lockup

Please let me know if you require any additional information.

[eriknyquist]

Thanks @khanning, we'll take a look.

Side Note: you don't need to handle the timing of CurieIMU reads, anymore-- there is a dataReady() method you can use now, e.g.

CurieIMU.dataReady(ACCEL);               // returns true if a new accel sample is available
CurieIMU.dataReady(GYRO);                // returns true if a new accel sample is available
CurieIMU.dataReady(ACCEL | GYRO);  // returns true if both are available......

[russmcinnis]

I was able to reproduce the issue using your peripheral sketch running with an Arduino101 central

[khanning]

@eriknyquist @russmcinnis thanks for confirming the issue and for the note on the dataReady() method. Please let me know if there is anything else I can do to help with the issue.

[russmcinnis]

works with the dataReady() but we can still reproduce it with the change. I will see what Erik thinks.

[SidLeung]

@russmcinnis

Did you observe any BLE advertisement prior to the lock up? You may need the Ellisys to monitor this...
If you can't see any Adv Data packets, you may want to modify the sketch to have control over when the IMU starts. Let see how the two modules affect each other. Thanks.

[russmcinnis]

@khanning @eriknyquist @SidLeung I have the test running with the Ellisys scanning. I am using our latest corelibs and I haven't been able to reproduce the failure. It was failing within a few minutes last week on previous corelibs. I will let this run for a while longer and report back.

[russmcinnis]

issue495.zip

Finally crashed it. Ellisys trace attached.
@khanning @eriknyquist @SidLeung
The peripheral that crashed has address: 98:4F:EE:0C:0E:DE and local name LED. Looks like the write request packet is missing from the last write transaction. The test was just staying connected and alternating writiing 0x0 and 0x1 every 1 second from the central to the peripheral that is using IMU and BLE.

[russmcinnis]

tracked by jira 906

[aitorhh]

I have been checking this issue and the workaround I have found is to use interruptions. Unfortunately, it's not suitable for my case.

The arduino sketch and test can be found at: imu_ble.ino

I have also try to read the IMU values surrounded by noInterrupts() and interrups() but no luck.

Hope this information rings a bell to someone :)

[aitorhh]

I did some more experiments with IMU and BLE, but anyway, here are some ?conclusions?:

• noInterrups()/interrupts() helps to postpone the crash

Here is the code I used for the testing, arduino sketch and nodejs script.

Sampling control with setAccelerometerRate()/setGyroRate() without protecting the readMotionSensor() with noInterrupts()/`interrupts():

• Sampling rate == 25 Hz no crash within
• Sampling rate > 25 Hz, crash in less than ~10s (1, 3, 11, 3, 3 s)

Sampling control with setAccelerometerRate()/setGyroRate() with protecting the readMotionSensor() with noInterrupts()/`interrupts():

• Sampling rate <= 100 Hz no crash within at least 15h (900min)
• Sampling rate > 200 Hz crash in less than ~1s

Using CurieTimer to trigger readMotionSensor() and handle on ISR:

• Sampling rate <= 100 Hz no crash within at least 10min
• Sampling rate > 200 Hz crash in less than ~1s

The problem on my previous comment was that I wasn't changing the sampling rate :S.