Starting a new thread from a BLE callback

RE: Starting a new thread from a BLE callback

bachelor — Mon, 14 Jun 2021 11:26:56 GMT

Found the problem now: thread_data was declared inside the callback function, so it lies at address &thread_data on the Bluetooth stack . It is therefore not a valid address for other threads. As a consequence the MPU recognizes a memory access violation. When I declared it outside the callback function the problem went away.

RE: Starting a new thread from a BLE callback

bachelor — Mon, 14 Jun 2021 11:20:37 GMT

Thanks for taking the time to answer. It didn't work for me though. But I have a solution now, I will post it in a separate answer.

RE: Starting a new thread from a BLE callback

smackenzie — Mon, 14 Jun 2021 00:09:03 GMT

I had a similar problem trying to start advertising from a uart interrupt.

The problem came from zephyr attempting to aquire the lock for a semaphore, but zephyr disallows this inside interrupts. https://github.com/zephyrproject-rtos/zephyr/blob/c9aa260f0cfc54453aef70f876e9ba9385428a30/kernel/sem.c#L121

I suspect this is a similar issue.

My solution was to create the thread on the main execution, then inside the uart interrupt, feed the data to the thread with a fifo.

K_FIFO_DEFINE(rx_fifo);

static void uart_irq(...){
    uart_data_t * data = static_cast < uart_data_t *>(k_malloc(sizeof(uart_data_t)));
    ...
    k_fifo_put(&rx_fifo, data);
}


static void uart_hander_thread(void *, void *, void *) {
   uart_data_t* data_ptr = static_cast <uart_data_t*>(k_fifo_get(&rx_fifo, K_FOREVER));
   // Handle data
   
   k_free(data_ptr);
}

I assume using a worker thread would also resolve this, but I have not tested it.

docs.zephyrproject.org/.../workqueues.html