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

APP TWI schedule/perform function is getting blocked/struck randomly when in use with BLE UART profile

renganathan

I am trying to build a device to stream the 9 axis sensor data from the I2C based sensor and then transmit it using BLE UART profile. It is sampled every 3 seconds using app timer with the callback functionality. After successively being able to read and transmit the value using BLE UART, randomly TWI schedule/perform gets blocked. Can you guys suggest the possibility of where it could go wrong ?

  • 0

    This is likely a matter of interrupt priorities. Maintaining the BLE connection have highest priority, and therefore BLE connection events will delay other tasks. The Interrupt model and processor availability chapter in the SoftDevice spec covers this in detail, and particularly BLE peripheral connection processor usage patterns is relevant (assuming your device is a BLE peripheral).

    You could increase the priority of your app timer where you schedule TWI transfers to APP_HIGH and see if that improves the situation. However, you cannot be confident to sample your sensor in exact intervals, as BLE must have priority in order to not miss connection events.

    The way I read your question I do not think it is relevant in this case. However, if you just need a short interval where you know with confidence that you will have the CPU and other resources exclusively for the application, you can use the Timeslot API, which grants timeslots where the application have exclusive access to the chip. (Note that the length of these timeslots are short, as it is scheduled between connection events.)

  • 0 in reply to Einar Thorsrud

    Hi. Thanks a lot for your reply. I am not too keen on sampling at the exact time spot. But the firmware is crashing, as the after a while TWI gets struck and after sometime BLE disconnects due to timeout error. Like you said I think I am having some issues with interrupt priorties. I am not able to use medium or high priority for TWI as it is causing the softdevice to crash and disconnect. The highest possible is LOW which is what I am using for TWI and as well by default app timer is also set at LOW. Even when the TWI is blocked, timer was working. I have to see if this leads me anywhere. Else I will be interested in using Timeslot as each sensor is maximum of 400ms and from docs it looks possible to accomdate of the above timeslot.

  • 0 in reply to Einar Thorsrud

    Have you used a debugger to see what happens when you see the "crash"? You should be able to get a long way with help of the error handling in the SDK by disabling optimization (set it to 0) and defining "DEBUG" globally for the project.

    While it will be a lot easier to make suggestions after you have debugged the case properly, I would want to make sure that you have a large enough scheduler queue size (given in the second parameter to APP_SCHED_INIT()). It is not unlikely that you will end up with more elements in the queue when you have an active BLE link, which would delay execution of scheduled events.

  • 0 in reply to Einar Thorsrud

    Sure. I will be on it and get back once I get to know the problem.

Related
Terms of service