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

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.

@Adam: Are you saying that simply switching to mbed-src caused the hang to go away? or did you also switch timestamp_t to 32-bit?

@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

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

Excellent and thanks for the help!

-Adam