Enabling BT causes CPU halt. A bug?

[cab938]

I'm very new to embedded programming and the whole zephyr toolchain, so apologies for the naivety here. I'm using the Seeeduino Xiao BLE Sense device (https://docs.zephyrproject.org/latest/boards/arm/xiao_ble/doc/index.html) and have a j-link mini EDU which I'm using to program it. When I enable bluetooth in my prj.conf file with:

CONFIG_BT=y
CONFIG_BT_DEVICE_NAME="Test Beacon"

Then re-flash the device, it halts immediately with a BusFault (image below). Is there something else I need to configure in Kconfig to enable bluetooth? I don't actually have any bluetooth code written yet, so the exact same project without the two Kconfig values set deploys to the device fine.

[cab938]

I attempted to build an MWE. I create a new project based off of blinky and verified that it works correctly. Then I started to add in things in my prj.conf, when I use this (which is the same as my full build), I get a BusError immediately on attaching the ozone debugger:

CONFIG_GPIO=y

CONFIG_DEBUG_THREAD_INFO=y
CONFIG_DEBUG_OPTIMIZATIONS=y

# Setup logging and RTT
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y

# For sensor access
CONFIG_I2C=y
CONFIG_SPI=y
CONFIG_SENSOR=y

# Required to log floats
CONFIG_LOG_MODE_DEFERRED=y
CONFIG_CBPRINTF_FP_SUPPORT=y

# Bluetooth configuration
CONFIG_BT=y
CONFIG_BT_DEVICE_NAME="Test Beacon"

If I comment out the two lines beginning with CONFIG_BT it works as expected.

If I leave the CONFIG_BT lines in, but comment out everything but the CONFIG_GPIO (which blinky needs), it also works.

So I'm a bit at a loss here, mostly in that I don't totally understand what is happening with each of these marcos. I'm assuming that that these config options build out zephyr OS and that for some reason different macros (are they macros?) are resulting in different builds that don't work on this hardware. What should I do next to debug?

Note: this has been tried with two different devices, to eliminate a hardware defect.

[hermabe]

Some things to check:

• Check the log output if there is any additional info or fault-handler printout
• Run addr2line on the offending instruction address
• You are compiling with CONFIG_DEBUG_OPTIMIZATIONS=y, some stack sizes may need to be increased

are they macros?

They are kconfigs (https://docs.zephyrproject.org/latest/build/kconfig/index.html)

[cab938]

Thanks @hermabe , I'll check these log lines. I found that when I turned off compile with debug (e.g. -oO) and instead compiled for size things just started to work. There was enough ram/rom on the device with debug, where would I modify the stack size? (Can I modify the stack size?)

[hermabe]

That sounds like a stack overflow then. The fault handler output should say which thread it was. Threads usually have a kconfig for the stack size, eg. https://docs.zephyrproject.org/latest/kconfig.html#CONFIG_MAIN_STACK_SIZE for the main thread. It is also possible to use the thread analyzer to see the stack usage for each thread.

[cab938]

Thanks @hermabe ! I'm going to have to up my dev infrastructure I think and get some emulation going to test things faster. Right now the toolchain is a bit too opaque for me (west, rkonfig, whatever nrf connect is doing, then the segger interface for debugging) so I'm not sure where I would even put such modifications. But this is great for me to dive into and exactly the pointer I needed!