BLE_HeartRate sample code hangs for uncertain reason

The sample code "BLE_HeartRate" is working as it should on the nRF51822-mkit.
But, the dummy heart rate reading stops reporting to App when the code is running for a hour or two.
When aforementioned issue happen, the HRS is still alive in which, the mkit is still able to be disconnected and connected again but no heart rate reading is coming back and no more blinky of led1.
For me it feels like the S110 is still operate, however the application hangs (the while loop should run forever) for some reasons.
I enable WDT to eliminate the hanging problem and it works but I just like to know where it goes wrong in the first place.
Any comments are appreciated

BTW, the mbed folder revision is 91, nRF51822 is 69 and BLE_API is 123 in my case.

The sample code "BLE_HeartRate" is working as it should on the nRF51822-mkit.
But, the dummy heart rate reading stops reporting to App when the code is running for a hour or two.
When aforementioned issue happen, the HRS is still alive in which, the mkit is still able to be disconnected and connected again but no heart rate reading is coming back and no more blinky of led1.
For me it feels like the S110 is still operate, however the application hangs (the while loop should run forever) for some reasons.
I enable WDT to eliminate the hanging problem and it works but I just like to know where it goes wrong in the first place.
Any comments are appreciated
BTW, the mbed folder revision is 91, nRF51822 is 69 and BLE_API is 123 in my case.

I suspect that this is caused by the switch to using 64-bit timestamp values that was introduced after revision 88 of the mbed SDK. There have been some fixes in this area recently but in my humble opinion the whole timestamp switch to 64-bit should be reverted unless the underlying ticker maintenance code is switched to 64-bit as well.

I was able to delete the mbed library from the BLE_HearRate sample in the online compiler and then load the following library in its place so that I can could access the latest mbed SDK fixes:

Once I made that switch, the sample ran for several hours on my nRF51822-mkit.

I hope that helps,

Adam

I suspect that this is caused by the switch to using 64-bit timestamp values that was introduced after revision 88 of the mbed SDK. There have been some fixes in this area recently but in my humble opinion the whole timestamp switch to 64-bit should be reverted unless the underlying ticker maintenance code is switched to 64-bit as well.
I was able to delete the mbed library from the BLE_HearRate sample in the online compiler and then load the following library in its place so that I can could access the latest mbed SDK fixes:
<<library /users/mbed_official/code/mbed-src/>>
Once I made that switch, the sample ran for several hours on my nRF51822-mkit.
I hope that helps,
Adam

I have seen this issue sometimes; but could never track it down properly; especially since it happens after several hours, and I would always be working on something else when I encountered it.

It seems from your description that the BLE stack is stable and usable while the application/timers/or something else in mbed goes awry to cause a hang. Adding printf() to capture state transitions during ticker callbacks masks the issue; I haven't been able to reprduce the problem with printfs.

I admit that switching to 64-bit timestamp_t has been a wonky transition; especially since the underlying us_tickers are 32-bit on all platforms. I'm going to switch to 32-bit timestamps for testing; and if that allows me to get long runs without hangs, then I'll make a pull request for it.

Thanks for drawing attention to this issue. I realize that I was hoping to sweep it under the rugs; that was a poor approach.

rohit.

Hi,
I have seen this issue sometimes; but could never track it down properly; especially since it happens after several hours, and I would always be working on something else when I encountered it.
It seems from your description that the BLE stack is stable and usable while the application/timers/or something else in mbed goes awry to cause a hang. Adding printf() to capture state transitions during ticker callbacks masks the issue; I haven't been able to reprduce the problem with printfs.
I admit that switching to 64-bit timestamp_t has been a wonky transition; especially since the underlying us_tickers are 32-bit on all platforms. I'm going to switch to 32-bit timestamps for testing; and if that allows me to get long runs without hangs, then I'll make a pull request for it.
Thanks for drawing attention to this issue. I realize that I was hoping to sweep it under the rugs; that was a poor approach.
rohit.

Yes, once I switched to the latest mbed-src it did run for several hours. I see one change in us_ticker_api.c with commit 63cad which helped.

-Adam

@Rohit,
Yes, once I switched to the latest mbed-src it did run for several hours. I see one change in us_ticker_api.c with [[https://github.com/mbedmicro/mbed/commit/63cad2a60bc2b0c5a1f41dcd3f446b5e325669c3#diff-932f83990ac5d12b41f73d8e83042a2c | commit 63cad]] which helped.
-Adam

@Adam: That's lovely to know. We'll be making a new release of the mbed-sdk today (or very shortly); and that should help spread the recent fix around timestamp_t. I'll continue testing with the switch to 32-bit timestamp_t.

@Adam: That's lovely to know. We'll be making a new release of the mbed-sdk today (or very shortly); and that should help spread the recent fix around timestamp_t. I'll continue testing with the switch to 32-bit timestamp_t.

We'll be making a new release of the mbed-sdk today (or very shortly); and that should help spread the recent fix around timestamp_t. I'll continue testing with the switch to 32-bit timestamp_t.

Excellent and thanks for the help!

-Adam

<<quote rgrover1>>
We'll be making a new release of the mbed-sdk today (or very shortly); and that should help spread the recent fix around timestamp_t. I'll continue testing with the switch to 32-bit timestamp_t.
<</quote>>
Excellent and thanks for the help!
-Adam

Important Information for this Arm website

This site uses cookies to store information on your computer.
By continuing to use our site, you consent to our cookies.
If you are not happy with the use of these cookies, please review our
Cookie Policy
to learn how they can be disabled.
By disabling cookies, some features of the site will not work.