Starting a new thread from a BLE callback

[bachelor]

Hi, I have a BLE service:

BT_GATT_SERVICE_DEFINE(lres_svc,

    BT_GATT_PRIMARY_SERVICE(BT_UUID_LRES),

    BT_GATT_CHARACTERISTIC(BT_UUID_LRES_STAT, BT_GATT_CHRC_NOTIFY,

                   BT_GATT_PERM_NONE, NULL, NULL, NULL),

    BT_GATT_CCC(lec_ccc_cfg_changed,

            BT_GATT_PERM_READ | BT_GATT_PERM_WRITE),

    BT_GATT_CHARACTERISTIC(BT_UUID_LRES_EXP, BT_GATT_CHRC_WRITE,

                   BT_GATT_PERM_WRITE, NULL, exp_settings_cb, NULL),

);

In the callback exp_settings_cb I would like to start a new thread, which I tried to do like this: First I defined stack size etc:

#define STACK_SIZE 1024

#define MY_PRIORITY 7

K_THREAD_STACK_DEFINE(stack_area, STACK_SIZE);

void testThread1(void *a, void *b, void *c) {

    printk("sth\n");

    return;

}

The callback itself looks like this:

static ssize_t exp_settings_cb(struct bt_conn *conn, const struct bt_gatt_attr *attr,

             const void *buf, uint16_t len, uint16_t offset, uint8_t sth)

{

    

    struct k_thread thread_data;

    k_tid_t my_tid = k_thread_create(&thread_data, stack_area,

                                 K_THREAD_STACK_SIZEOF(stack_area),

                                 testThread1,

                                 NULL, NULL, NULL,

                                 MY_PRIORITY, K_USER, K_NO_WAIT);

    return 0;

}

The problem is when I trigger the callback by writing to the corresponding characteristic I get:

00> [00:00:13.605,834] <err> os: ***** MPU FAULT *****
00> [00:00:13.605,865] <err> os:   Instruction Access Violation
00> [00:00:13.605,865] <err> os: r0/a1:  0x20000bd0  r1/a2:  0x20000bd0  r2/a3:  0x20000b68
00> [00:00:13.605,865] <err> os: r3/a4:  0x00000401 r12/ip:  0x20000bc0 r14/lr:  0x200001ec
00> [00:00:13.605,865] <err> os:  xpsr:  0x00000000
00> [00:00:13.605,865] <err> os: Faulting instruction address (r15/pc): 0x200001ec
00> [00:00:13.605,865] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
00> [00:00:13.605,895] <err> os: Current thread: 0x200051f0 (unknown)
00> [00:00:13.828,582] <err> os: Halting system
00> [00:00:00.609,588] <inf> sx127x: SX127x version 0x12 found
00> *** Booting Zephyr OS version 2.5.99  ***

After I included

CONFIG_USERSPACE=y

CONFIG_MAIN_STACK_SIZE=4096

into my prj.conf I got a different error:

00> [00:00:17.488,342] <err> os: ***** HARD FAULT *****
00> [00:00:17.488,342] <err> os:   Fault escalation (see below)
00> [00:00:17.488,342] <err> os: ***** MPU FAULT *****
00> [00:00:17.488,372] <err> os:   Stacking error (context area might be not valid)
00> [00:00:17.488,372] <err> os:   Data Access Violation
00> [00:00:17.488,372] <err> os:   MMFAR Address: 0x200099d0
00> [00:00:17.488,372] <err> os: r0/a1:  0x200089d8  r1/a2:  0x0000efed  r2/a3:  0x20001ff4[0m
00> [00:00:17.488,372] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000001 r14/lr:  0x00000000
00> [00:00:17.488,403] <err> os:  xpsr:  0x2001863c
00> [00:00:17.488,403] <err> os: Faulting instruction address (r15/pc): 0x20000fa4
00> [00:00:17.488,403] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
00> [00:00:17.488,403] <err> os: Fault during interrupt handling

The thread creation works perfectly fine when trying it inside main though.

I would greatly appreciate any insights that might help solve this problem.

Thank you!

[smackenzie]

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

[bachelor]

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.

[bachelor]

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.