-----Original Message-----
From: Laczen JMS [mailto:laczenjms@...]
Sent: 06 September 2017 16:58
To: Cufi, Carles <Carles.Cufi@...>
Cc: Johan Hedberg <johan.hedberg@...>; zephyr-
devel@...
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Carles,

2017-09-06 16:30 GMT+02:00 Cufi, Carles <Carles.Cufi@...>:

Hi Jehudi,

-----Original Message-----
From: Laczen JMS [mailto:laczenjms@...]
Sent: 06 September 2017 15:46
To: Cufi, Carles <Carles.Cufi@...>
Cc: Johan Hedberg <johan.hedberg@...>; zephyr-
devel@...
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Carles,


2017-09-06 15:26 GMT+02:00 Cufi, Carles <Carles.Cufi@...>:

Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@...
[mailto:zephyr-devel- bounces@...] On Behalf
Of Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard
Fault

Hi Johan,

I increased the stack size to CONFIG_BT_RX_STACK_SIZE=2048 (I
don't understand why the real stack size is reported to be 2348),
anyhow it gives a new hard fault (but now with assert: '0'

failed):

Kernel stacks:
main (real size 512): unused 220 usage 292 / 512

(57

%)

idle (real size 256): unused 200 usage 56 / 256 (21

%)

interrupt (real size 2048): unused 1640 usage 408 / 2048

(19

%)

workqueue (real size 2048): unused 1668 usage 380 / 2048

(18

%)

prio recv thread stack (real size 748): unused 440 usage 308

/

748

(41 %)
recv thread stack (real size 2348): unused 308 usage 2040

/

2348 (86 %)
[bt] [ERR] isr_rx_conn_pkt_ctrl: assert: '0' failed
***** HARD FAULT *****
Executing thread ID (thread): 0x200023dc
Faulting instruction address: 0x12d50 Fatal fault in ISR!

Spinning...

This is a BLE Controller assert that hit. Can you give us a couple
of

additional tidbits of info to help us diagnose?

* What exact Zephyr version are you running? (if master please give
us the commit SHA)

I am using the latest zephyr version (pulled yesterday), commit
d3862d7b39349b079b0d125de0c27e54a41b8aa4

So that's the latest, excludes some fixes that came in some days ago.

Thanks.

* What board are you using? Is this a combined (Host + Controller

single-chip) build or are you using 2 chips?

I am using a andtcl board with nrf51822 256kb flash and 32kb ram

Not sure what board that is, can you send a link?

It is a module from aliexpress:
https://nl.aliexpress.com/store/product/1pc-Wireless-Module-32K-RAM-
256K-FLASH-NRF51822-Nordic-51822-core-with-PCB-antenna-intergrated-
NRF51822/605000_32801747596.html

* What configuration are you using? (your .conf file)

Included are the conf file from the mesh source directory, as well as
the .config files from the output directory

Got your config files, so this is a combined build with Host +

Controller on a single chip. What would be interesting to know in this
case is more info about the peer devices you are interacting with. Can
you give us a clue of what dongles/chips/devices are you connecting to,
what brand they are and what version? Also the number of simultaneous
connections you have at any one time, and the general description of the
setup you are running in terms of chips and stacks.

I am running meshctl from bluez (development version) as a provisioner,
there are no other devices connected. The dongle I am using with meshctl
is a Trust BT dongle (dmesg reports Product:
CSR8510 A10). I have also enabled debugging in zephyr
(CONFIG_BT_DEBUG_HCI_DRIVER=y) included is the logging

Thanks for all the info.

Before we investigate whether the CSR8510 is doing something it should not, can we double-check additional stack sizes?

Can you set:
CONFIG_BT_HCI_TX_STACK_SIZE to 1024
and
CONFIG_BT_RX_STACK_SIZE to as much as you can, 4096 ideally

I see that your receive thread stack (CONFIG_BT_RX_STACK_SIZE) is getting near the 2048 limit, which is huge. Are you doing a lot of complex operations in BLE callbacks?

Thanks,

Carles