• State Verified Answer
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 3232 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 120680
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Restarted Timer is not executed for long time(S132)

Moritz

Hey,

SHORT VERSION: Timer (every Second) gets started when connecting (BLE with nRF Connect) to my DK (SDK12.2, Softdevice S132). Timer gets stopped when disconnecting. After reconnecting it takes more than 15Sec for the Timer to call the handler again. When the handler finally gets called again it gets called often directly after each call, afterwards it starts to work normal again.

LONG VERSION: At the moment I`m implementing my first own Service into ble_app_template (SDK 12.2, Softdevice S132) Everything works fine so far, so I wanted to Implement a feature, that the Timer is only started, when in a valid BLE connection.

So I start my timer, when I get an BLE_GAP_EVT_CONNECTED and I stop it when I get BLE_GAP_EVT_DISCONNECTED. The first time I connect through nRF Connect (After DK reset) everything works fine and I get my NRF_LOG_INFO everytime my Timer is called instantly. Also my Characteristic updates when I Enable notifications. When I disconnect the timer stops and I don't get updates anymore through my LOG.

Now comes the part, that confuses me. If I reconnect now, I get my NRF_LOG_INFO, that I went through the function that starts my timer again, and the return Code of starting the Timer is NRF_SUCCESS. Nevertheless most of the time nothing happens for even longer than 15 Seconds (But sometimes really quick). Afterwards all the past Interrupts get handled at once (I have one every second) and afterwards everything works fine and the handler gets called every second.

While waiting for the Timer to start again it is no problem to get value updates from nRF Connect or enable / disable notifications. The only thing delayed is the timer.

QUESTIONS: Is the Chip busy for such a long time so my timeouts get queued? But if it`s busy, why can I read values through the nRF Connect app? Is this behavior normal? Does it help if I switch to a scheduler? How can I speed this up?

Greetings

P.S.: It's hard to give you code because, the ble_app_template is quite huge itself, but if it helps, I can upload the whole project.

Parents
  • FormerMember
    0 FormerMember

    It should be perfectly possible to start and stop a timer upon a connect and disconnect, respectively?

    It would be very nice if I can see/test the code, could you upload it? Also, which version of S132 do you use?

    Update 24.03.2017: I think the problem is related to app_timer, calling the app_timer a BLE interrupt context.To call the app_timer a BLE interrupt context, the scheduler should be used. The ble_app_hids_mouse example uses the the scheduler for the battery level update, I would recommend you to take a look at it.

    For reference, I have attached a version of ble_app_template (SDK 13, S132 v.4.0.2), that uses the scheduler and calls app_timer in a BLE interrupt context (BLE_GAP_EVT_CONNECTED and BLE_GAP_EVT_DISCONNECTED), similar to your project: ble_app_template_122411_devzone.zip

Reply
  • FormerMember
    0 FormerMember

    It should be perfectly possible to start and stop a timer upon a connect and disconnect, respectively?

    It would be very nice if I can see/test the code, could you upload it? Also, which version of S132 do you use?

    Update 24.03.2017: I think the problem is related to app_timer, calling the app_timer a BLE interrupt context.To call the app_timer a BLE interrupt context, the scheduler should be used. The ble_app_hids_mouse example uses the the scheduler for the battery level update, I would recommend you to take a look at it.

    For reference, I have attached a version of ble_app_template (SDK 13, S132 v.4.0.2), that uses the scheduler and calls app_timer in a BLE interrupt context (BLE_GAP_EVT_CONNECTED and BLE_GAP_EVT_DISCONNECTED), similar to your project: ble_app_template_122411_devzone.zip

Children
  • 0 in reply to FormerMember

    Thanks. Everyting works now. But I have one question and one suggestion.In your main you do advertising_init(); and then services_init(); If you have custom uuids you adv. the other way around is better. devzone.nordicsemi.com/.../ mentioned here. Maybe you can include that in the SDK13 examples. Or is there an explicit reason why you did it the other way around?

    The other part is regarding the ble_stack_init(); Took me some time, to figure out I had to explicitely set ble_cfg.common_cfg.vs_uuid_cfg.vs_uuid_count = 1; otherwise I get a NRF_ERROR_NO_MEM In sd_ble_uuid_vs_add. In the SDK 12 example you didnt have to do that, and the code looks quite different. Is the only difference you dont get the default parameters and configure everything yourself?

    Thanks a lot for your help!

  • FormerMember
    0 FormerMember in reply to FormerMember

    Yes, I agree. In ble_app_template, services_init() should be placed before advertising_init() to take into account the cases where custom UUIDs are being used. In ble_app_uart, it is done like that. I will report it for improvement internally.

    I don't know why the explicit setting for vendor specific UUIDs is removed in SDK 13, since almost all the other settings are kept. It could have been mentioned in the migration note..

Related