Date   

Re: Bluetooth mesh sample (mesh) - Hard Fault

Chettimada, Vinayak Kariappa
 

Hi Jehudi,

Thank you for the quick response. (btw, I am on #zephyrproject with nickname vich, if that’s faster to communicate)

It was a local intiated slave feature req that is not support by the peer BT 4.0 implementation while the peer had initiated a channel map update.

I will send a fix soon to github and email you the patch.

-Vinayak

-----Original Message-----
From: Laczen JMS [mailto:laczenjms@gmail.com]
Sent: Thursday, September 07, 2017 9:28 AM
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-devel@lists.zephyrproject.org; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
Subject: Re: [Zephyr-devel] Bluetooth mesh sample (mesh) - Hard Fault

Hi Vinayak,

With the diff applied I got the following:

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 4396): unused 2356 usage 2040 / 4396 (46 %)
Unknown Rsp to 14, in 2 state
[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-07 8:56 GMT+02:00 Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>:
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@gmail.com]
Sent: Wednesday, September 06, 2017 10:30 PM
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-devel@lists.zephyrproject.org; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
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@nordicsemi.no>:
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@nordicsemi.no>
wrote:

Hi Jehudi,

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

Hi Carles,

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

Hi Jehudi,

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

Hi Carles,


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

Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel- bounces@lists.zephyrproject.org] On Behalf Of
Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

Hi Vinayak,

With the diff applied I got the following:

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 4396): unused 2356 usage 2040 / 4396 (46 %)
Unknown Rsp to 14, in 2 state
[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-07 8:56 GMT+02:00 Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>:

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@gmail.com]
Sent: Wednesday, September 06, 2017 10:30 PM
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-devel@lists.zephyrproject.org; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
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@nordicsemi.no>:
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@nordicsemi.no> wrote:

Hi Jehudi,

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

Hi Carles,

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

Hi Jehudi,

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

Hi Carles,


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

Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel- bounces@lists.zephyrproject.org] On Behalf Of
Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


zephyr - bdaddr_t

Tamra Oyama <tamrako@...>
 

Hi Zephyr Team,

I am trying to compile a bluetooth application in the zephyr folder. I am trying to use the data type 'bdaddr_t', but I keep getting the error below:

error: unknown type name ‘bdaddr_t’

I have included in my main file.
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <errno.h>
#include <signal.h>
#include <misc/printk.h>

#include <bluetooth/bluetooth.h>
#include <bluetooth/hci.h>

I could not find bdaddr in any of the zephyr files. From what I have researched, bdaddr_t is the basic data structure used to specify a Bluetooth device address and that all Bluetooth address in BlueZ will be stored and manipulated as bdaddr_t structures. Furthermore, BlueZ allows for ba2str and vice versa conversions easily. Is there an equivalent to this in zephyr? I feel like this is a fundamental feature for all programs dealing with Bluetooth.

Thank you,
Tamra


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@gmail.com]
Sent: Wednesday, September 06, 2017 10:30 PM
To: Chettimada, Vinayak Kariappa
<vinayak.kariappa.chettimada@nordicsemi.no>
Cc: zephyr-devel@lists.zephyrproject.org; Cufi, Carles
<Carles.Cufi@nordicsemi.no>
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@nordicsemi.no>:
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@nordicsemi.no> wrote:

Hi Jehudi,

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

Hi Carles,

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

Hi Jehudi,

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

Hi Carles,


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

Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel- bounces@lists.zephyrproject.org] On Behalf Of
Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

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@nordicsemi.no>:

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@nordicsemi.no> wrote:

Hi Jehudi,

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

Hi Carles,

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

Hi Jehudi,

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

Hi Carles,


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

Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel- bounces@lists.zephyrproject.org] On Behalf
Of Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Question regarding to implement a UDP client using net_app APIs

Michael Scott <michael.scott@...>
 

On 09/06/2017 03:11 AM, Robert.CH.Chou@acer.com wrote:
Hi,
I’m comparing implement a UDP client by using net_app and net_context APIs.
When using net_context APIs, I’m able to send and receive data from any peer (register receive callback through net_context_recv()).
Since UDP is connectionless, it’s an expected behavior as long as I don’t call net_context_connect().
However, if I use net_app APIs to implement a UDP client, it seems that I’m unable to do the same thing.
I’m able to send out the data to the requested peer by calling net_app_send_pkt().
However, I’m unable to receive the data from the peer by registering the receive callback through net_app_set_cb() and without calling net_app_connect().
Is this an intended behavior of net_app API?
Yes, for net_app APIs, this is expected behavior if the UDP client makes use of the net_app_connect() function (required if using DTLS).

I noticed this as well when porting the LwM2M library to net_app APIs recently.

- Mike

Robert
==---------------------------------------------------------------
This email contains information that is for sole use of the intended recipient and may be confidential or privileged.If you are not the intended recipient, any further review, disclosure, copying, distribution, or use of this email, or the contents of this email is prohibited. Please notify the sender by reply this email and destroy the original email if your receipt of this email is in error.
---------------------------------------------------------------==!!
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: Bluetooth mesh sample (mesh) - Hard Fault

Chettimada, Vinayak Kariappa
 

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


Re: Bluetooth mesh sample (mesh) - Hard Fault

Carles Cufi
 

Hi Jehudi,

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

Hi Carles,

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

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

Hi Carles,


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

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel- bounces@lists.zephyrproject.org] On Behalf
Of Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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


Re: Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

Hi Carles,

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

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

Hi Carles,


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

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel- bounces@lists.zephyrproject.org] On Behalf Of
Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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,

Carles
Kind regards,

Jehudi


Re: Bluetooth mesh sample (mesh) - Hard Fault

Carles Cufi
 

Hi Jehudi,

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

Hi Carles,


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

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org
[mailto:zephyr-devel- bounces@lists.zephyrproject.org] On Behalf Of
Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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?


* 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.

Thanks,

Carles


Re: Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

Hi Carles,


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

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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

* 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

* 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


Thanks,

Carles
Kind regards,

Jehudi


Re: Bluetooth mesh sample (mesh) - Hard Fault

Carles Cufi
 

Hi Jehudi,

-----Original Message-----
From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-
bounces@lists.zephyrproject.org] On Behalf Of Laczen JMS
Sent: 06 September 2017 15:20
To: Johan Hedberg <johan.hedberg@intel.com>
Cc: zephyr-devel@lists.zephyrproject.org
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)
* What board are you using? Is this a combined (Host + Controller single-chip) build or are you using 2 chips?
* What configuration are you using? (your .conf file)

Thanks,

Carles


Re: Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

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...

Kind regards,

Jehudi

2017-09-06 11:35 GMT+02:00 Johan Hedberg <johan.hedberg@intel.com>:

Hi Jehudi,

On Wed, Sep 06, 2017, Laczen JMS wrote:
Running the bluetooth mesh example (samples/bluetooth/mesh/) on a
nrf51822 results in a Hard Fault. The provisioner is meshctl (bluez).
After successful provisioning I disconnect from the mesh, when
connecting again the hard fault appears:

Kernel stacks:
main (real size 512): unused 228 usage 284 / 512 (55 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1656 usage 392 / 2048 (19 %)
workqueue (real size 1024): unused 676 usage 348 / 1024 (33 %)
prio recv thread stack (real size 448): unused 144 usage 304 / 448 (67 %)
recv thread stack (real size 1396): unused 32 usage 1364 / 1396 (97 %)
***** HARD FAULT *****
Executing thread ID (thread): 0x20001f04
Faulting instruction address: 0xf63c
Fatal fault in ISR! Spinning...

If needed I can provide more info/logging...
I'd bet the recv thread stack overflowed. It's already at 97% with only
32 unused bytes based on the above log. Try increasing its size to
something bigger. The Kconfig variable is called CONFIG_BT_RX_STACK_SIZE.

Johan


Question regarding to implement a UDP client using net_app APIs

Robert Chou
 

Hi,

 

I’m comparing implement a UDP client by using net_app and net_context APIs.

 

When using net_context APIs, I’m able to send and receive data from any peer (register receive callback through net_context_recv()).

Since UDP is connectionless, it’s an expected behavior as long as I don’t call net_context_connect().

 

However, if I use net_app APIs to implement a UDP client, it seems that I’m unable to do the same thing.

I’m able to send out the data to the requested peer by calling net_app_send_pkt().

However, I’m unable to receive the data from the peer by registering the receive callback through net_app_set_cb() and without calling net_app_connect().

 

Is this an intended behavior of net_app API?

 

Robert

==---------------------------------------------------------------
This email contains information that is for sole use of the intended recipient and may be confidential or privileged.If you are not the intended recipient, any further review, disclosure, copying, distribution, or use of this email, or the contents of this email is prohibited. Please notify the sender by reply this email and destroy the original email if your receipt of this email is in error.
---------------------------------------------------------------==!!



Re: Bluetooth mesh sample (mesh) - Hard Fault

Johan Hedberg
 

Hi Jehudi,

On Wed, Sep 06, 2017, Laczen JMS wrote:
Running the bluetooth mesh example (samples/bluetooth/mesh/) on a
nrf51822 results in a Hard Fault. The provisioner is meshctl (bluez).
After successful provisioning I disconnect from the mesh, when
connecting again the hard fault appears:

Kernel stacks:
main (real size 512): unused 228 usage 284 / 512 (55 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1656 usage 392 / 2048 (19 %)
workqueue (real size 1024): unused 676 usage 348 / 1024 (33 %)
prio recv thread stack (real size 448): unused 144 usage 304 / 448 (67 %)
recv thread stack (real size 1396): unused 32 usage 1364 / 1396 (97 %)
***** HARD FAULT *****
Executing thread ID (thread): 0x20001f04
Faulting instruction address: 0xf63c
Fatal fault in ISR! Spinning...

If needed I can provide more info/logging...
I'd bet the recv thread stack overflowed. It's already at 97% with only
32 unused bytes based on the above log. Try increasing its size to
something bigger. The Kconfig variable is called CONFIG_BT_RX_STACK_SIZE.

Johan


Bluetooth mesh sample (mesh) - Hard Fault

laczenJMS
 

Hi,

Running the bluetooth mesh example (samples/bluetooth/mesh/) on a
nrf51822 results in a Hard Fault. The provisioner is meshctl (bluez).
After successful provisioning I disconnect from the mesh, when
connecting again the hard fault appears:

Kernel stacks:
main (real size 512): unused 228 usage 284 / 512 (55 %)
idle (real size 256): unused 200 usage 56 / 256 (21 %)
interrupt (real size 2048): unused 1656 usage 392 / 2048 (19 %)
workqueue (real size 1024): unused 676 usage 348 / 1024 (33 %)
prio recv thread stack (real size 448): unused 144 usage 304 / 448 (67 %)
recv thread stack (real size 1396): unused 32 usage 1364 / 1396 (97 %)
***** HARD FAULT *****
Executing thread ID (thread): 0x20001f04
Faulting instruction address: 0xf63c
Fatal fault in ISR! Spinning...

If needed I can provide more info/logging...

Kind regards,

Jehudi


Re: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

Maciej Dębski <maciej.debski@...>
 

Hello,

a quick thought - did you try to write in Hello World example the following lines?
$ make help
$ make BOARD=<board_name>
$ make BOARD=<board_name> flash
$ make BOARD=<board_name> debug

Try to use these. Also, be sure you installed all linux prerequisites:
https://www.zephyrproject.org/doc/getting_started/installation_linux.html

Good luck,
Maciej Dębski

On Wed, Sep 6, 2017 at 2:52 AM, Nashif, Anas <anas.nashif@...> wrote:

Hi,

You need to install the SDK, it seems line you are missing this step. Please follow the instructions in the getting started guide to install the SDK, then point the variables to the directory where you have installed it.

 

Please use the zephyr-devel@ mailing list, not zephyr-builds@

 

Anas

 

From: zephyr-builds-bounces@lists.zephyrproject.org [mailto:zephyr-builds-bounces@lists.zephyrproject.org] On Behalf Of ???
Sent: Tuesday, September 5, 2017 4:40 AM
To: zephyr-builds@lists.zephyrproject.org
Subject: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

 

Hi, it is the first time to use zephyr so I am little clumsy for understanding this RTOS. Thankyou for understanding.

 

I am using Linux 16.xx 64bit.

 

I tried to follow https://www.zephyrproject.org/doc/getting_started/getting_started.html to compile and build the hello-world.

 

I have cloned this->>git clone https://github.com/zephyrproject-rtos/zephyr.git   at the Desktop folder.

 

 

As you see the screen-shot above, I exported like that. (I am not sure the SDK_INSTALL_DIR's exact directory, please tell me if I got the wrong directory)

 

I did source zephyr-env.sh

 

Finally I type make to build the hello-world and I got these error.

 

 

please give me some advise. Thank you 

Image removed by sender.

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

Nashif, Anas
 

Hi,

You need to install the SDK, it seems line you are missing this step. Please follow the instructions in the getting started guide to install the SDK, then point the variables to the directory where you have installed it.

 

Please use the zephyr-devel@ mailing list, not zephyr-builds@

 

Anas

 

From: zephyr-builds-bounces@... [mailto:zephyr-builds-bounces@...] On Behalf Of ???
Sent: Tuesday, September 5, 2017 4:40 AM
To: zephyr-builds@...
Subject: [Zephyr-builds] Hello, I have some questions for building hello-world samples.

 

Hi, it is the first time to use zephyr so I am little clumsy for understanding this RTOS. Thankyou for understanding.

 

I am using Linux 16.xx 64bit.

 

I tried to follow https://www.zephyrproject.org/doc/getting_started/getting_started.html to compile and build the hello-world.

 

I have cloned this->>git clone https://github.com/zephyrproject-rtos/zephyr.git   at the Desktop folder.

 

 

As you see the screen-shot above, I exported like that. (I am not sure the SDK_INSTALL_DIR's exact directory, please tell me if I got the wrong directory)

 

I did source zephyr-env.sh

 

Finally I type make to build the hello-world and I got these error.

 

 

please give me some advise. Thank you 

Image removed by sender.

 


Re: Remove/change fs_truncate() API

David Brown
 

On Tue, Sep 05, 2017 at 10:18:01AM +0200, Andrzej Kaczmarek wrote:

I'm not really sure if this needs to be POSIX compliant - the Jira ticket for
adding filesystem APIs states that it is designed after POSIX but is not POSIX
compliant. For example, fs_open() does not have flags which could be used to
truncate existing file when opening, so it would cover one of possible
scenarios here. But perhaps something changed since then, don't know.
Perhaps we should change the API to add the truncate option to
fs_open(), at least provided at least one underlying implementation
supports this.

Yes, currently I return ENOTSUP for this. My only concern here is that this
means there is no way to open existing file and truncate it other than
fs_unlink() + fs_open() due to missing flags in fs_open() I mentioned above.
BTW, does it make sense to have fs_truncate() work for '0' as offset and return
e.g. EINVAL for other values? This should be doable I think.
Only if the fs_truncate() for 0 offset can be implemented atomically.
I'm not sure how that would work for operations given by file
descriptor, since the file is already opened.

I think there should be as little between the Zephyr fs API and the
NFFS API. A developer using a filesystem on an embedded system needs
to understand what is happening (and specifically what will happen if
power is interrupted during an operation). That means we should avoid
having API calls that try to simulate behavior that isn't there.

For example, if fs_truncate() somehow were to use fs_open() by
figuring out the filename the existing file descriptor used, and
opening with truncation in NFFS, this would cause an additional file
descriptor to be used for the operation (even if just momentarily).
In a system design, it is possible that the developer will configure
the exact number of file descriptors available, which could cause this
operation to either mysteriously fail, or succeed, but use the file
descriptor temporarily, causing another thread's filesystem operation
to fail.

So, my suggestion would be to add the O_TRUNC (or equivalent) flag to
open, make fs_truncate() return ENOTSUP, and just document this. If
arbitrary truncation, or truncation of an open file is desired, that
can be added later to NFFS, and then to the API.

David


Re: Remove/change fs_truncate() API

Andrzej Kaczmarek
 

Hi David,

On Mon, Sep 4, 2017 at 5:17 PM, David Brown <david.brown@...> wrote:
On Mon, Sep 04, 2017 at 09:27:30AM +0200, Andrzej Kaczmarek wrote:

I was trying to implement fs_truncate() for NFFS but this does not
seem to be possible in a reasonable way, at least not with current
NFFS API. The only option I see now is to copy contents to new file
and unlink old one, but this has obvious disadvantages: it's slow, we
may easily run out of space etc.

If your goal is posix compliance, this isn't going to be right anyway.
truncate is required to be atomic.

The POSIX truncate call is also allowed to be used to extend the size
of a file.

​I'm not really sure if ​this needs to be POSIX compliant - the Jira ticket for adding filesystem APIs states that it is designed after POSIX but is not POSIX compliant. For example, fs_open() does not have flags which could be used to truncate existing file when opening, so it would cover one of possible scenarios here. But perhaps something changed since then, don't know.
 
So do we really need option to truncate any opened file to any size?
In Mynewt there's only option to truncate file to 0 when opening it by
specifying flag to fs_open() and this seems to be just enough. There
seems to be not many references to fs API right now (actually
Bluetooth subsystem is the only one) so perhaps we could just remove
fs_truncate() and allow truncate to 0 using something else?

My proposal would be one of:
- add flag to fs_open()
- make fs_truncate() truncate file specified by *path* to 0

The reason why I'd prefer to have truncation done by *path* instead of
*fp* is because it's simpler to implement in NFFS since what needs to
be done is to unlink old file and create new one. The API to create
new file takes full path as a parameter so having fp only makes it a
bit more complicated.

I think it would be better to return ENOTSUP than to implement it in a
non-compliant way.  My suggestion would be to document it as not
supported, and make a ticket to add support to NFFS for truncation
later.

​Yes, currently I return ENOTSUP for this. My only concern here is that this means there is no way to open existing file and truncate it other than fs_unlink() + fs_open() due to missing flags in fs_open() I mentioned above.
BTW, does it make sense to have fs_truncate() work for '0' as offset and return e.g. EINVAL for other values? This should be doable I think.
 
David

​Best regards,
Andrzej​

5201 - 5220 of 8521