This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Supporting a real-time task

My 51822 needs to support some realtime control code that runs for about 75mS. During that time I need to mask all interrupts. With a logic analyzer I can see that my realtime code is getting interrupted every 25mS or so, I guess by the SoftDevice. I tried using CRITICAL_REGION_ENTER/CRITICAL_REGION_EXIT but that does not mask the interrupts.

  1. How can I mask interrupts so that my realtme code will not be interrupted no matter what the radio is doing?
  2. Is there a way to do this such that I don't unduly disturb the SoftDevice?

Regards, Bret

  • Audun,

    Like many real-time tasks, mine happens asynchronously in response to a GPIO signal. When that signal occurs, I have just a couple of mS to begin the control loop. I can't wait for the radio to give me a time window.

    It sounds like the best approach is to disable the radio at the start of my real-time task or perhaps to break the connection or stop advertising. I recognize that this might disrupt the BLE stack and I'm willing to re-init the stack or even do a software reset when my real-time task is over.

    So my question is now this: If I am willing to disrupt the BLE communication, is there a way to asynchronously prevent interrupts from the radio?

    Thanks, Bret

  • Hi Bret,

    in that case, you need to drop the connection or stop advertising. There are no mechanisms to forcibly skip radio events as far as I know.

    Stopping advertising is an immediate action, however there is a corner-case when a connection request is received at the same time as advertising is stopped. Doing a proper disconnect will take more than a couple of ms, so that's not an option. The only way to immediately halt all radio activity is to disable the softdevice using sd_softdevice_disable(). Note that the Central will consider the link active until the Supervision Timeout has expired, and will typically not attempt to reconnect until that happens.

  • Audun,

    I just tried the approach where I stop advertising during my r/t task (by calling sd_ble_gap_adv_stop). I see a connection timeout in the MCP when I do this. And then when I start advertising again my application hangs. I suspect this is because the connection is now stale in the SoftDevice and restarting advertising on a stale connection corrupts the SoftDevice.

    I'm not seeing any BLE events from the SoftDevice when the connection timeout occurs so I guess I need to make some sort of API call to see if the connection is stale and then re-establish the connection before I can resume advertising. Can you give me more details about how I might do that?

    Thanks, Bret

  • Another detail. It turns out that sd_ble_gap_adv_stop hangs if the device is connected to the MCP. I guess I need to force a disconnect before my r/t task.

  • I was a bit unclear regarding advertising and connections I think. What I meant was that there are two different states where the softdevice will interrupt the application: When advertising, and when in a connection.

    Advertising is stopped by sd_ble_gap_adv_stop(). When you are in a connection, with the MCP for example, sd_ble_gap_adv() won't do anything.

    A proper disconnect (sd_ble_gap_disconnect()) involves letting the peer device know that are disconnecting, which can take some time depending on the specific connection parameters.

    There's also a corner-case while advertising: if the peer device initiates a connection at the same time as you stop advertising you might actually be in a connected state instead of stopping all activity. The only way to be sure there's no radio interrupts is to disable the softdevice using sd_softdevice_disable()

Related