We are trying to set up Zephyr on an nrf52832 to run a HCI interface. Due to hardware limitations we are obliged not to use flow control and thus the H:5 HCI (three wire UART) together with bluez 5.54 We have disabled flow control in the DTS overlay.
We have tried to using west build -t menuconfig
with the standaard hci uart zephyr example to activate the H5. But this is not working because it is on the controller side not the client side witch we need.
We found on the net, the current HCI UART example and the tip that @carlesc gave us. You can find the source here: code. I have compiled my linux kernel with Bluez 3wire support and I connect using hciattach /dev/ttyUSB0 3wire 1000000 noflow nosleep
. Linux recognizes the adapter and attaches it but then the system crashes with the following log:
00> [00:00:44.900,909] <err> os: ***** MPU FAULT *****
00> [00:00:44.900,909] <err> os: Stacking error (context area might be not valid)
00> [00:00:44.900,909] <err> os: Data Access Violation
00> [00:00:44.900,939] <err> os: MMFAR Address: 0x20006230
00> [00:00:44.900,939] <err> os: r0/a1: 0xedf4f9de r1/a2: 0x48854818 r2/a3: 0xaaaaaaaa
00> [00:00:44.900,970] <err> os: r3/a4: 0xaaaaaaaa r12/ip: 0xffffffff r14/lr: 0x00000009
00> [00:00:44.900,970] <err> os: xpsr: 0x61000000
00> [00:00:44.900,970] <err> os: Faulting instruction address (r15/pc): 0x00016bf0
00> [00:00:44.900,970] <err> os: >>> ZEPHYR FATAL ERROR 2: Stack overflow on CPU 0
00> [00:00:44.901,000] <err> os: Current thread: 0x20000890 (unknown)
00> [00:00:45.324,310] <err> os: Halting system
I have tried arm-none-eabi-addr2line -e zephyr/build/zephyr/zephyr.elf 0x16bd0
to determen where the error ecures. I got this response zephyrproject/zephyr/kernel/queue.c:280
I have tried changing the CONFIG_BT_HCI_TX_STACK_SIZE
size, CONFIG_MAIN_STACK_SIZE
and the CONFIG_ASSERT=y
in the nrf52sdk_nrf52832.conf But this has changed nothing.
The error seems to occur when the connection is established. After the connection is established the zephyr code crashes on the net_buf_get
function.
I think you were on the right track trying to increase the CONFIG_MAIN_STACK_SIZE in the prj.conf file. I would further increase to multiples of 512 (1024, 2048, 4096) until you don't get a stack overflow anymore.
I had the same issue with Zephyr RTOS and a task with nested functions over several levels.