• State Suggested Answer
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 69 subscribers
  • Views 5288 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 213662
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Timer intermittently finishes too soon, rare conflict between app_timer and ble_advertising

Jake

Config

  • Using NRF52810 on a custom PCB with 32kHz + 32MHz crystals, very close to the reference schematic
  • S112 with SDK 14.2.0 in SEGGER Embedded Studio V3.30

A button press from a sleeping state triggers an app_button interrupt which calls ble_advertising_start() followed by app_timer_start() and then nrf_gpio_pin_write() to turn on an LED. The timer ends after 50ms and turns off the LED. Advertising lasts 5 seconds. 

Normal behaviour

This works almost every time as expected, a 50ms LED flash when the button is pressed and 5s of advertising. 

Problem

The problem seems quite rare and I can't forcefully reproduce it because I don't yet understand how it's happening. Around 1 in 50 times (rough estimate) when pressing the button to wake from sleep, the LED will flash for a very short period (you have to hold it up to your eye to see it) and will keep doing short flashes on button presses until advertising stops 5s later. It seems that it will only get into this state when waking from sleep (4uA with 32kHz type sleep) and won't fall into this state by pressing the button if the device is already advertising. 

In this short-lived state where you see very short LED flashes, the advertising seems to work properly but connection attempts fail. The system isn't resetting, all the data is still fine after recovering from this state. Interestingly, if I put the ble_advertising_start() line at the end instead of the start; more often than not, the LED will flash but advertising fails to start completely. 

The problem is really quite hard to reproduce so I wouldn't recommend trying, I'm also unable to share my project. I'm just hoping that someone who knows more about the internals of the SDK might have a better idea of which direction to look to solve this. 

  • How can starting advertising cause an app_timer to finish way too early?
  • Is this even related to advertising, or does app_timer get itself confused on its own?
  • Might this be 32kHz crystal related? 

Thanks for any suggestions in advance :)

  • 0 in reply to Jake

    I can't see any obvious reasons that the timer should run 10x longer. Did you start the LFCLK before app_timer? This is required if the softdevice is not initialized. The NO_MEM error is most likely caused by the OP_QUEUE being too small. Please try increasing APP_TIMER_CONFIG_OP_QUEUE_SIZE. Are you calling the timer start functions from interrupt context? Is there something else running on higher priority in your application that can delay the handling of the interrupts?

  • 0 in reply to Jørgen Holmefjord

    This is pretty much the first thing that happens in main() when the device is started. After LOG is initialised, app_timer and gpio is configured and the led_flash_for_ms() happens after. The old app_timer would work like this, regardless of whether the softdevice was enabled or not. 

    Seems that when using app_timer2, the end event never actually gets called, so the LED never goes off. The long flash time I was seeing was because something else was disabling the LED much further in the program. 

    The V2 timer is failing to run my timeout handler before or after softdevice is enabled, or even if I enable and select LFCLK manually. I've even tried lowering APP_TIMER_CONFIG_IRQ_PRIORITY but it still won't ever trigger my timeout handler for some reason. 

    (I'll get to the memory problem after I've got the first part working! OP_QUEUE_SIZE default definitely seems large enough but I'll see if increasing it solves the problem when I get there).

  • 0 in reply to Jake

    Can you share your project? I can help you debug it and try to get it working with app_timer2.

  • 0 in reply to Jørgen Holmefjord

    Thanks Jorgen, I'm afraid I can't share the project in its current state, it's almost production firmware now with the exception of this bug! I think what I'm going to do is try the full migration from 14.2 to 15, as I'm not happy with this squashed NRFX into 14.2 and the mess I now have here! I'll get back to you at some point and let you know how it goes, for now I'll mark your first answer as suggested answer Slight smile

Related