Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 4 months ago.
Tickers crash/hang on the nRF51822, especially when multiple Tickers & a Softdevice are used.
This is a bit of a cross-post from an issue on the github page but I'm hoping it may reach a wider audience and/or someone with some insight.
The github link is here: https://github.com/mbedmicro/mbed/issues/1533
When using Tickers on the nRF51 platform it seems things get missed or interrupts generated can collide just perfectly so as to effectively crash all the application-level interrupts and cause the app to "freeze" whilst any Softdevice running underneath continues happily onwards (but having nothing to send from the application).
Is anyone else experiencing this problem? Anyone found a quick & dirty way to fix?
How about using the nRF51822-SDK app_timer API directly? I know changes to the mbed Ticker function aimed at fixing older, worse versions of this bug replaced using the app_timer with using the directly-controller RTC1 timer on the nRF51822 but this seems to have just shrunk the problem so it's unlikely rather than really solved...
1 Answer
8 years, 4 months ago.
Hi
I think I hit this bug too, and is weird because it looks like it never goes back to the main, the i2c becomes crazy and the aplication freezes. But the bluetooth part keeps working.
My problem seems to happen after a 30 minutes, sometimes more.
I have an i2c with mpu6050, 3 interrupt driven buttons.
I have no idea what causes this, however I try to avoid it using only one ticker.
use this inside your while (more) loop or while (1) or whatever you use inside main to poll your sensors
if (sensors) { read_none_count = 0; } else { read_none_count++; if (read_none_count > 3) { read_none_count = 0;
LOG("I2C may be stuck @ %d\r\n", sensor_timestamp); mbed_i2c_clear(MPU6050_SDA, MPU6050_SCL); 0 data in 3 ticks, re-initilize accelerometer hardware } }
Thats what I found in another project on my 6050 (not my code) but when the sensors read nothing for a period of time it sends the command to clear and restart the unit.
Hope this helps, Ray
posted by 14 Jan 2017
There is a race condition in the NRF ticker code, but I don't actually now if this is the cause and if solving it would help your issue.
posted by Erik - 13 Jul 2016Hey there. Would you be able to expand on what you mean or point me in the right direction to see the potential problem you are talking about?
I'm currently finding, through debugger in Keil that when this bug hits it seems that no Ticker-related interrupts fire but ALL the softdevice/BLE derived callbacks in my application work fine. Furthermore flags/things that get set in BLE callback that should then get reset in main() never get reset. So it seems like the app is never returning to main() from this semi-crashed context.
I'm using one SPI & one I2C device and another possible symptom / cause is that the I2C port seems to die / go-nuts when this bug hits... There is a very old issue that describes these symptoms with I2C... https://developer.mbed.org/questions/3729/Question-about-the-communication-between/
Any tips welcome! My own exploration continues.
posted by CJ Shaw 13 Jul 2016