Re: Bluetooth mesh sample (mesh) - Hard Fault


Chettimada, Vinayak Kariappa
 

Hi Jehudi,

This is very helpful.

The local controller (if I assume correct, is in slave role) is under channel map update waiting for the instant when it received an unknown rsp PDU.

Please apply a modified diff that is attached, which will let me know which procedure from local controller could have been initiated (if so) that the peer sent an unknown rsp.

Thanks in advance.

-Vinayak

-----Original Message-----
From: Laczen JMS [mailto:laczenjms@...]
Sent: Wednesday, September 06, 2017 10:30 PM
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@...>
Cc: zephyr-devel@...; Cufi, Carles
<Carles.Cufi@...>
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Vinayak and Carles,

I applied the patch and increased stack sizes as required, it took some time
before I got the error again. The result:

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 %)
[bt] [WRN] proxy_ccc_write: Client wrote 0x0000 instead enabling notify
prio recv thread stack (real size 748): unused 440 usage 308 / 748 (41 %)
recv thread stack (real size 4396): unused 2968 usage 1428 / 4396 (32 %)
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 %)
tx stack (real size 940): unused 512 usage 428 / 940 (45 %)
Unknown Rsp to 2.
[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...

Kind regards,

Jehudi

2017-09-06 17:43 GMT+02:00 Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@...>:
Hi Jehudi,

To further debug the conditions around the assert, please apply the
attached diff.
And send me which assert is hit.

Regards,
Vinayak

On 6 Sep 2017, at 17:05, Cufi, Carles <Carles.Cufi@...> wrote:

Hi Jehudi,

-----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
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

Join devel@lists.zephyrproject.org to automatically receive all group messages.