xQueueSend on pico w freezes the system

Kernel
1

I have btstack running in a freertos task on a raspberry pi pico w, waiting for events on a queue. When I send to the queue from another task, the system freezes and the call never returns from xQueueSend:

QueueHandle_t btstack_event_queue;

int main(void) {
  stdio_init_all();

  btstack_event_queue = xQueueCreate(10, sizeof(unsigned long));
...
}

void ledTask(void *params) {
  while (true) {
    cyw43_arch_gpio_put(CYW43_WL_GPIO_LED_PIN, 1);
    vTaskDelay(1000);
    cyw43_arch_gpio_put(CYW43_WL_GPIO_LED_PIN, 0);
    vTaskDelay(1000);

    unsigned long ulVar = 10UL;
    if (btstack_event_queue != 0) {
      xQueueSend(btstack_event_queue, (void *)&ulVar, (TickType_t)10);
    }
    vTaskDelay(1000);
  }
}

The bt task contains:


  while(true) {
    unsigned long event;
    if (btstack_event_queue != 0) {
      if (xQueueReceive(btstack_event_queue, &event, portMAX_DELAY)) {
        // att_server_request_can_send_now_event(con_handle);
      }    
    }
    vTaskDelay(5000);
  }

The system freezes on the first call to xQueueSend.

2

It was actually down to the client automatically connecting and requesting data. I saw a call to:

att_server_request_can_send_now_event(con_handle);

in the BT attWriteCallback where it checks for:

ATT_CHARACTERISTIC_ORG_BLUETOOTH_CHARACTERISTIC_TEMPERATURE_01_CLIENT_CONFIGURATION_HANDLE

When it then schedules a data send to the client the system freezes. It makes sense I think as the ledTask can send data out as it sends data into the BT task via the queue but the client comes in through a callback, presumably outwith the context of the BT task.

Preventing it sending data out on a client notification solves the problem and the queue is working perfectly, allowing the task to send data over bluetooth by sending the data in the queue to the bluetooth task.

Just have to do the same for incoming requests from clients and route them to a queue for the BT task to process.

3

Thank you for reporting back!