Possible Ticker BLE_API conflict causing problems with Nordic devices?

[seajayshore]

Apologies if you've seen this before as this, or related issues, have appeared on other parts of the mbed forum/github. I now believe it's potentially a bug with the BLE_API so I'm posting an updated issue here.

When using Tickers in combination with the BLE_API & Softdevice on Nordic targets the application can unexpectedly hang. The Ticker interrupts stop firing and (from debug in Keil) it seems the code never returns to main().

I'm struggling to find out exactly what is causing this but I suspect that multiple things have control over the Nordic RTC1 timer device and at the wrong moment they can both collide or reset things and stop the application Tickers from firing.

There are seemingly related versions of this issue here:
ARMmbed/mbed-os#1533
https://developer.mbed.org/questions/3729/Question-about-the-communication-between/
https://developer.mbed.org/questions/69710/Tickers-crashhang-on-the-nRF51822-especi/

But few concrete answers so far.

Related to this, I recently read this older BLE_API issue: #89
That describes problems with the mbed-classic implementation of the BLE_API. It says (and code confirms) that a Ticker/Timeout object is used within callbacks in the BLE_API (if using mbed-classic).

Can anyone confirm/deny if this older issue is what is causing these current problems? Otherwise any ideas on a fix for this Ticker issue?

[ciarmcom]

ARM Internal Ref: IOTSFW-2794

[pan-]

@seajayshore Tickers are not used anymore by implementation of BLE API on Nordic platforms.
Your ticker issue is more likely related to an overflow in the ticker code.
Investigations are still going on.

[seajayshore]

@pan- Thanks v. much for the update! :-)

Ah, OK, I see. There is a Timeout used in nRF5xGap.h in the ble-nrf51822 library I thought was getting called, but I seem to have been wrong.

So if I drive all interrupts / periodic updates to my app via the radioNotificationCallback in Gap.h, and remove my application-level Ticker, I should avoid this Ticker issue altogether right? (Unless another Ticker is being used by some other library obviously).

[pan-]

@seajayshore The radio notification callback is a terrible way to drive anything (it should be removed at some point ...). The best would be to wait for a patch and still use the Ticker.

[seajayshore]

OK, thanks for the straight-up advice! I'll follow! :-)

Maybe I'll have to look at using the Nordic app_timer of some lower level API using the RTC1 timer.

[rgrover]

any activity done through radio notification callbacks can potentially delay the radio from doing timing sensitive operations. Radio notification callback handler should be very brief.

[seajayshore]

OK, thanks for the tip. It's only setting a single flag variable in the callback context so should be ok I guess.
In anycase my application is working much more reliably having removed the normal ticker & using the radiocallback flag. Issue from my point of view is I now have no/limited control over frequency of this callback as its determined by the connection interval from the central.