Date   

Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Johan Hedberg
 

Hi Vikrant,

On Wed, Dec 06, 2017, Vikrant More wrote:
static void publish(struct k_work *work)
{

static unsigned char onoff=0;
static unsigned char tid=0;
int err;

struct net_buf_simple *msg = NET_BUF_SIMPLE(2+4+2);

bt_mesh_model_msg_init(msg, OP_GEN_ONOFF_SET_UNACK);
net_buf_simple_add_u8(msg, onoff=onoff^0x01);
net_buf_simple_add_u8(msg, tid++);

printk("Interrupted....data_send=%u\n\r",onoff);

*root_models[2]*.pub->msg=msg;
This is not safe since the publishing buffer is not expected to be
allocated on the stack. It will cause a crash as soon as the Publish
Retransmit state is set to a non-zero value. I pointed this out earlier
to Steve and also tried to document it better:

https://lists.zephyrproject.org/pipermail/zephyr-devel/2017-November/008457.html

So in your case you'd want to create the buffer when you define the
publication struct, i.e. something like:

static struct bt_mesh_model_pub pub = {
.msg = NET_BUF_SIMPLE(2+4+2),
};

And then before publishing you'd do the same bt_mesh_model_msg_init()
and net_buf_simple_add_u8() calls as you do now.

When I publish using *root_models[2] *then function
bt_mesh_model_publish(struct bt_mesh_model *model) from
zephyr/subsys/bluetooth/host/mesh/access.c
execute properly after pressing the Button1 on nRF52840-PDK.

root_models[2] is server model.

Its publish address assigned by provisioner = 0xC000
It is subscribed to address = 0xC001

So all other nodes not changed their LED1 status when I pressed Button1
from any one of the Board since others are subscribed to 0xC001.

But when I hard-coded ctx.addr = 0xC001; in bt_mesh_model_publish(struct
bt_mesh_model *model) then ohter boards start to toggle LED1.
This looks like an issue with the provisioner (or how you use it) since
it seems it should also be setting the publication address to 0xc0001.

So I used root_model[4] i.e BT_MESH_MODEL_ID_GEN_ONOFF_CLI.

In this case, after pressing button, function bt_mesh_model_publish() returns
error as -> bt_mesh_model_publish: err:-49

On investigating, I found that this is because of

if (pub->addr == BT_MESH_ADDR_UNASSIGNED) {
return -EADDRNOTAVAIL;
}

That means Silicon Labs MESH APP does not assign any Public address to this
client model.
Ideally it should be 0xC001 since other NODEs are subscribed to it. Am I
right ?
Yes, sounds correct to me, i.e. this is an issue on the
provisioner/configuration client side.

Johan


Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Hello Sir,

I have attached my main.c with this email. (from Zephyr Mesh Demo)

This main.c is mostly inspired from information provided by Steve Brown. 

Please check it.

Here,

root_models[2] is BT_MESH_MODEL_ID_GEN_ONOFF_SRV
root_models[4] is BT_MESH_MODEL_ID_GEN_ONOFF_CLI

------------------------------------------------------------------------------------------------------------------------------------------
static void publish(struct k_work *work)
{

    static unsigned char onoff=0;
    static unsigned char tid=0;
    int err;

    struct net_buf_simple *msg = NET_BUF_SIMPLE(2+4+2);

    bt_mesh_model_msg_init(msg, OP_GEN_ONOFF_SET_UNACK);
    net_buf_simple_add_u8(msg, onoff=onoff^0x01);
        net_buf_simple_add_u8(msg, tid++);

    printk("Interrupted....data_send=%u\n\r",onoff);

    root_models[2].pub->msg=msg;

    err = bt_mesh_model_publish(&root_models[2]);
    if (err) {
        printk("bt_mesh_model_publish: err: %d\n\r", err);
    }

}
-----------------------------------------------------------------------------------------------------------------------------------------

When I publish using  root_models[2] then function  bt_mesh_model_publish(struct bt_mesh_model *model) from zephyr/subsys/bluetooth/host/mesh/access.c 
execute properly after pressing the Button1 on nRF52840-PDK.

root_models[2] is server model.

Its publish address assigned by provisioner = 0xC000
It is subscribed to address = 0xC001

So all other nodes not changed their LED1 status when I pressed Button1 from any one of the Board since others are subscribed to 0xC001.

But when I hard-coded ctx.addr = 0xC001; in bt_mesh_model_publish(struct bt_mesh_model *model) then ohter boards start to toggle LED1.

I know this is wrong way to publish since we have to use client model to publish anything.
------------------------------------------------------------------------------------------------------------------------------------------

So I used root_model[4] i.e BT_MESH_MODEL_ID_GEN_ONOFF_CLI.

In this case, after pressing button, function bt_mesh_model_publish() returns error as -> bt_mesh_model_publish: err:-49

On investigating, I found that this is because of

if (pub->addr == BT_MESH_ADDR_UNASSIGNED) {
        return -EADDRNOTAVAIL;
    } 

That means Silicon Labs MESH APP does not assign any Public address to this client model.
Ideally it should be 0xC001 since other NODEs are subscribed to it. Am I right ?

--------------------------------------------------------------------------------------------------------------------------------------------

Am I on right track ?

When I follow Steve's code & increase .net_transmit = BT_MESH_TRANSMIT(5, 20) upto 5, then reliability is almost 100%.

Plus THREAD calls bt_mesh_model_publish( ) on every click even if I pressed button multiple times
in short period of time.

I will appreciate your suggestions if there are any. Please guide me what to do next.
I thoroughly want to understand everything before building my final application.

Thank You for your support !!


On Tue, Dec 5, 2017 at 11:09 PM, Vikrant More <vikrant8051@...> wrote:
I have added bt_mesh_model_publish( ) in thread which starts to execute after getting interrupt from button. But when I click button multiple times in very short period of time then only thread executes but 
bt_mesh_model_publish( ) never get called.



On Dec 5, 2017 10:32 PM, "Vikrant More" <vikrant8051@...> wrote:
Currently noob like me don't known how to correctly fine tuned or configure or write code from scratch using Zephyr so that it will exactly work like Nordic Semiconductor Mesh Light_Switch Demo. 

Hence I am requesting you to provide simple demo for nrf52840-PDK board. To find out what nordic has done differently, person should have knowledge of entire stack  & currently you are only one who knows everything. 

Coding style in Zephyr Mesh & nordic Mesh SDK is not simple C. It is objective C, so very difficult to visualize everything.

Plus #NordicSemiconductor code is very complicated compare to your coding style. 

I agree with you that coexistence of GATT & ADV Bearer may be reason of less reliability of data transfer.

So currently, I can do is wait till nordic implement GATT Bearer in their Mesh SDK to check overall performance or till they release Android App with ADV-provisioner utility.


On Dec 5, 2017 9:19 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
> But as per my testing, zephyr publishing reliability is not good even if I
> call bt_mesh_model_publish() from thread which wakes up on interrupt.

This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan




Bluetooth power efficiency

Primini
 

Hi everyone!

I am using Nordic nrf52832 in my project and I have to set Bluetooth power consumption to a minimum level if possible in a certain period of times. I read in Nordic dev zone (https://devzone.nordicsemi.com/question/13984/completely-disabling-bluetooth/) some alternatives but it is not so clear how to achieve this. 

In my point of view stopping advertisement and disconnect all connected devices (which are possible using only Zephyr Bluetooth API) is enough for the hardware entering in a minimum power consumption level (like a disable/disconnected radio state). But if it does not, I could write a radio power register setting the radio to off in an intrusive way (http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fradio.html&cp=2_1_0_22_13_45&anchor=register.POWER). If I do that, is Zephyr Bluetooth driver able to handle the power off/on without any unwanted side effects? I mean, would be this a correct approach?

Regards,

T. Primini


Re: uart_pipe spinning problem for stm32

Erwan Gouriou
 

Ok, can you raise an issue in github?
We'll get it fixed.

On 5 December 2017 at 19:02, Dmitry Shmidt <dimitrysh@...> wrote:
On Tue, Dec 5, 2017 at 8:17 AM, Erwan Gouriou <erwan.gouriou@...> wrote:
> Hi Dmitry,
>
> Could you try something like:
> static int uart_stm32_irq_is_pending(struct device *dev)
> {
>     USART_TypeDef *UartInstance = UART_STRUCT(dev);
>
>     return ((LL_USART_IsActiveFlag_RXNE(UartInstance) &&
>                 LL_USART_IsEnabledIT_RXNE(UartInstance)) ||
>                (LL_USART_IsActiveFlag_TXE(UartInstance) &&
>                 LL_USART_IsEnabledIT_TXE(UartInstance)));
> }

This is working, thanks!


> Erwan
>
> On 1 December 2017 at 08:55, Michael Hope <michaelh@...> wrote:
>>
>> Hi Dmitry.  If it helps, uart_console is also used by the qemu_cortex_m3
>> board for the host networking interface. The serial driver [1] uses the
>> masked interrupt status reg (UARTMIS) [2 pg 460] and not the raw status
>> (UARTRIS).
>>
>> -- Michael
>>
>> [1]
>> https://github.com/zephyrproject-rtos/zephyr/blob/f3f0c03b86753f5c80570564832bd0159e2fa67f/drivers/serial/uart_stellaris.c#L546
>> [2] http://www.ti.com/lit/ds/symlink/lm3s6965.pdf
>>
>>
>> On 30 November 2017 at 18:48, Dmitry Shmidt via Zephyr-devel
>> <zephyr-devel@lists.zephyrproject.org> wrote:
>>>
>>> Hi Erwan,
>>>
>>> On Thu, Nov 30, 2017 at 1:28 AM, Erwan Gouriou <erwan.gouriou@...>
>>> wrote:
>>> > Hi Dmitri,
>>> >
>>> >
>>> > Can you explicit the functional issue, before we do any change?
>>> >
>>> > About TXE:
>>> > TXE is "TX ready", hence indeed likely to be often 1 indeed.
>>> >
>>> > Then, this code is located in isr callback, hence it is hit only on
>>> > UART
>>> > IRQ.
>>> > Having TXE set to TRUE at this step should not be an issue since we
>>> > check
>>> > rx_ready before read to discriminate if IRQ was actually raised for RX.
>>> >
>>> > Did I missed something?
>>>
>>> The problem is in uart_pipe_isr() logic. It is never-ending (spinning)
>>> after first
>>> time entrance: it is still processing RX but its nature doesn't allow any
>>> user
>>> threads to get control.
>>>
>>> uart_pipe_isr() is called on RX interrupt:
>>>
>>> static void uart_pipe_isr(struct device *unused) {
>>>          while (uart_irq_update(uart_pipe_dev)
>>>                    && uart_irq_is_pending(uart_pipe_dev)) {
>>>                 ...
>>>          }
>>>
>>> uart_irq_update() is always 1 and uart_irq_is_pending()
>>> is also always 1 (at least in case of stm32):
>>>          return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
>>>                      LL_USART_IsActiveFlag_TXE(UartInstance));
>>>
>>> So possible solutions as I can see are:
>>> 1) Use uart_irq_rx_ready() instead of  uart_irq_is_pending() in
>>>     while() in uart_pipe.c
>>>  2) Change uart_stm32_irq_is_pending() to return only RNXE -
>>>    however other drivers also return RXE || TXE
>>> 3) Mask TXE as Michael suggested that is actually (2).
>>>
>>> > Erwan
>>> >
>>> > On 30 November 2017 at 01:07, Dmitry Shmidt via Zephyr-devel
>>> > <zephyr-devel@lists.zephyrproject.org> wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> In uart_pipe.c code:
>>> >> static void uart_pipe_isr(struct device *unused)
>>> >> {
>>> >>         ARG_UNUSED(unused);
>>> >>
>>> >>         while (uart_irq_update(uart_pipe_dev)
>>> >>                   && uart_irq_is_pending(uart_pipe_dev)) {
>>> >> ...
>>> >> }
>>> >>
>>> >> uart_irq_update() is returning 1 and
>>> >> uart_irq_is_pending() is always TRUE for stm32, because
>>> >> despite RXNE is cleared, TXE is always 1.
>>> >> static int uart_stm32_irq_is_pending(struct device *dev)
>>> >> {
>>> >>         USART_TypeDef *UartInstance = UART_STRUCT(dev);
>>> >>
>>> >>         return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
>>> >>                    LL_USART_IsActiveFlag_TXE(UartInstance));
>>> >>
>>> >> TXE is always 1 probably by design because poll_out is working
>>> >> properly:
>>> >> static unsigned char uart_stm32_poll_out(struct device *dev,
>>> >>
>>> >> unsigned char c)
>>> >> {
>>> >>         USART_TypeDef *UartInstance = UART_STRUCT(dev);
>>> >>
>>> >>         /* Wait for TXE flag to be raised */
>>> >>         while (!LL_USART_IsActiveFlag_TXE(UartInstance))
>>> >>                 ;
>>> >>
>>> >> Please advise what is the right way to fix this issue:
>>> >> 1) Use uart_irq_rx_ready() instead of  uart_irq_is_pending() in
>>> >> while() in uart_pipe.c
>>> >> 2) Change uart_stm32_irq_is_pending() to return only RNXE -
>>> >> however other drivers also return RXE || TXE
>>> >> 3) Clear TXE during input processing
>>> >>
>>> >> Thanks,
>>> >> Dmitry
>>> >> _______________________________________________
>>> >> Zephyr-devel mailing list
>>> >> Zephyr-devel@lists.zephyrproject.org
>>> >> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>>> >
>>> >
>>> _______________________________________________
>>> Zephyr-devel mailing list
>>> Zephyr-devel@lists.zephyrproject.org
>>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>>
>>
>


Zephyr 1.10.0-rc2 tagged

Kumar Gala
 

Hi,

We have just tagged Zephyr 1.10.0-rc3. At this point we expect that v1.10.0 should be released in the next few days. We will be updating release notes over the next day or two and finishing of any release engineer efforts. If you have any bugs please open an issue and mark it as v1.10. The release notes are still work in progress, however a detailed log of the changes since v1.10.0-rc2 can be found here:


https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.10.0-rc3

Thanks

- k


Re: uart_pipe spinning problem for stm32

Dmitry Shmidt
 

On Tue, Dec 5, 2017 at 8:17 AM, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:
Hi Dmitry,

Could you try something like:
static int uart_stm32_irq_is_pending(struct device *dev)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

return ((LL_USART_IsActiveFlag_RXNE(UartInstance) &&
LL_USART_IsEnabledIT_RXNE(UartInstance)) ||
(LL_USART_IsActiveFlag_TXE(UartInstance) &&
LL_USART_IsEnabledIT_TXE(UartInstance)));
}
This is working, thanks!


Erwan

On 1 December 2017 at 08:55, Michael Hope <michaelh@juju.nz> wrote:

Hi Dmitry. If it helps, uart_console is also used by the qemu_cortex_m3
board for the host networking interface. The serial driver [1] uses the
masked interrupt status reg (UARTMIS) [2 pg 460] and not the raw status
(UARTRIS).

-- Michael

[1]
https://github.com/zephyrproject-rtos/zephyr/blob/f3f0c03b86753f5c80570564832bd0159e2fa67f/drivers/serial/uart_stellaris.c#L546
[2] http://www.ti.com/lit/ds/symlink/lm3s6965.pdf


On 30 November 2017 at 18:48, Dmitry Shmidt via Zephyr-devel
<zephyr-devel@lists.zephyrproject.org> wrote:

Hi Erwan,

On Thu, Nov 30, 2017 at 1:28 AM, Erwan Gouriou <erwan.gouriou@linaro.org>
wrote:
Hi Dmitri,


Can you explicit the functional issue, before we do any change?

About TXE:
TXE is "TX ready", hence indeed likely to be often 1 indeed.

Then, this code is located in isr callback, hence it is hit only on
UART
IRQ.
Having TXE set to TRUE at this step should not be an issue since we
check
rx_ready before read to discriminate if IRQ was actually raised for RX.

Did I missed something?
The problem is in uart_pipe_isr() logic. It is never-ending (spinning)
after first
time entrance: it is still processing RX but its nature doesn't allow any
user
threads to get control.

uart_pipe_isr() is called on RX interrupt:

static void uart_pipe_isr(struct device *unused) {
while (uart_irq_update(uart_pipe_dev)
&& uart_irq_is_pending(uart_pipe_dev)) {
...
}

uart_irq_update() is always 1 and uart_irq_is_pending()
is also always 1 (at least in case of stm32):
return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
LL_USART_IsActiveFlag_TXE(UartInstance));

So possible solutions as I can see are:
1) Use uart_irq_rx_ready() instead of uart_irq_is_pending() in
while() in uart_pipe.c
2) Change uart_stm32_irq_is_pending() to return only RNXE -
however other drivers also return RXE || TXE
3) Mask TXE as Michael suggested that is actually (2).

Erwan

On 30 November 2017 at 01:07, Dmitry Shmidt via Zephyr-devel
<zephyr-devel@lists.zephyrproject.org> wrote:

Hello,

In uart_pipe.c code:
static void uart_pipe_isr(struct device *unused)
{
ARG_UNUSED(unused);

while (uart_irq_update(uart_pipe_dev)
&& uart_irq_is_pending(uart_pipe_dev)) {
...
}

uart_irq_update() is returning 1 and
uart_irq_is_pending() is always TRUE for stm32, because
despite RXNE is cleared, TXE is always 1.
static int uart_stm32_irq_is_pending(struct device *dev)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
LL_USART_IsActiveFlag_TXE(UartInstance));

TXE is always 1 probably by design because poll_out is working
properly:
static unsigned char uart_stm32_poll_out(struct device *dev,

unsigned char c)
{
USART_TypeDef *UartInstance = UART_STRUCT(dev);

/* Wait for TXE flag to be raised */
while (!LL_USART_IsActiveFlag_TXE(UartInstance))
;

Please advise what is the right way to fix this issue:
1) Use uart_irq_rx_ready() instead of uart_irq_is_pending() in
while() in uart_pipe.c
2) Change uart_stm32_irq_is_pending() to return only RNXE -
however other drivers also return RXE || TXE
3) Clear TXE during input processing

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


Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

I have added bt_mesh_model_publish( ) in thread which starts to execute after getting interrupt from button. But when I click button multiple times in very short period of time then only thread executes but 
bt_mesh_model_publish( ) never get called.



On Dec 5, 2017 10:32 PM, "Vikrant More" <vikrant8051@...> wrote:
Currently noob like me don't known how to correctly fine tuned or configure or write code from scratch using Zephyr so that it will exactly work like Nordic Semiconductor Mesh Light_Switch Demo. 

Hence I am requesting you to provide simple demo for nrf52840-PDK board. To find out what nordic has done differently, person should have knowledge of entire stack  & currently you are only one who knows everything. 

Coding style in Zephyr Mesh & nordic Mesh SDK is not simple C. It is objective C, so very difficult to visualize everything.

Plus #NordicSemiconductor code is very complicated compare to your coding style. 

I agree with you that coexistence of GATT & ADV Bearer may be reason of less reliability of data transfer.

So currently, I can do is wait till nordic implement GATT Bearer in their Mesh SDK to check overall performance or till they release Android App with ADV-provisioner utility.


On Dec 5, 2017 9:19 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
> But as per my testing, zephyr publishing reliability is not good even if I
> call bt_mesh_model_publish() from thread which wakes up on interrupt.

This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan



Re: Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Luiz Augusto von Dentz
 

Hi Priyanka,

On Tue, Dec 5, 2017 at 5:30 PM, Priyanka Rawat <priyanka.rawat@nxp.com> wrote:
Hello

My test set up for IPv6 over BLE is following :

At one end : Two boards frdm-kw41z and frdm-k64f are stacked together.
kw41z (flashed with hci_blackbox firmware) is ble controller with k64f as
ble host (flashed with zephyr sample IPSP).
I assume hci_blackbox is not a zephyr based controller is it?

At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble
controller attached to Linux host.


[Kw41z (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble
controller)+Linux host]

Issue with testing IPv6 over BLE :

Once the BLE connection is established, within few seconds BLE controller
gets disconnected.
Either zephyr (recent master branch) crashes or BLE controller crashes or
both. Often it is BLE controller that gets disconnected within few seconds.
Restarting zephyr might enable establishing the connection once again, but
then ble controller goes down immediately.
Im not sure if will be able to help in case the controller is not
really zephyr based in the other hand we should be able to fix the
host crash if you provide some traces when that happens.

After that, I should disconnect the boards and connect again (via usb
connection) in order to set up the ble connection again.

While on Zephyr side, it always prints connection handle 32
On Linux side, the first time connection handle is 32, afterwards it is
different (handle 65, 128 etc.,) as shown with "hcitool conn".
btmon log shows for specific handle : remote user terminated connection or
connection terminated by local host
I guess with Zephyr the controller crashes and restart using the same
handle, while with Linux it manages to work fine, perhaps this is
because zephyr attempts to use the host flow control?


Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Currently noob like me don't known how to correctly fine tuned or configure or write code from scratch using Zephyr so that it will exactly work like Nordic Semiconductor Mesh Light_Switch Demo. 

Hence I am requesting you to provide simple demo for nrf52840-PDK board. To find out what nordic has done differently, person should have knowledge of entire stack  & currently you are only one who knows everything. 

Coding style in Zephyr Mesh & nordic Mesh SDK is not simple C. It is objective C, so very difficult to visualize everything.

Plus #NordicSemiconductor code is very complicated compare to your coding style. 

I agree with you that coexistence of GATT & ADV Bearer may be reason of less reliability of data transfer.

So currently, I can do is wait till nordic implement GATT Bearer in their Mesh SDK to check overall performance or till they release Android App with ADV-provisioner utility.


On Dec 5, 2017 9:19 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
> But as per my testing, zephyr publishing reliability is not good even if I
> call bt_mesh_model_publish() from thread which wakes up on interrupt.

This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan


Re: uart_pipe spinning problem for stm32

Erwan Gouriou
 

Hi Dmitry,

Could you try something like:
static int uart_stm32_irq_is_pending(struct device *dev)
{
    USART_TypeDef *UartInstance = UART_STRUCT(dev);

    return ((LL_USART_IsActiveFlag_RXNE(UartInstance) &&
                LL_USART_IsEnabledIT_RXNE(UartInstance)) ||
               (LL_USART_IsActiveFlag_TXE(UartInstance) &&
                LL_USART_IsEnabledIT_TXE(UartInstance)));
}

Erwan

On 1 December 2017 at 08:55, Michael Hope <michaelh@...> wrote:
Hi Dmitry.  If it helps, uart_console is also used by the qemu_cortex_m3 board for the host networking interface. The serial driver [1] uses the masked interrupt status reg (UARTMIS) [2 pg 460] and not the raw status (UARTRIS).

-- Michael



On 30 November 2017 at 18:48, Dmitry Shmidt via Zephyr-devel <zephyr-devel@lists.zephyrproject.org> wrote:
Hi Erwan,

On Thu, Nov 30, 2017 at 1:28 AM, Erwan Gouriou <erwan.gouriou@...> wrote:
> Hi Dmitri,
>
>
> Can you explicit the functional issue, before we do any change?
>
> About TXE:
> TXE is "TX ready", hence indeed likely to be often 1 indeed.
>
> Then, this code is located in isr callback, hence it is hit only on UART
> IRQ.
> Having TXE set to TRUE at this step should not be an issue since we check
> rx_ready before read to discriminate if IRQ was actually raised for RX.
>
> Did I missed something?

The problem is in uart_pipe_isr() logic. It is never-ending (spinning)
after first
time entrance: it is still processing RX but its nature doesn't allow any user
threads to get control.

uart_pipe_isr() is called on RX interrupt:

static void uart_pipe_isr(struct device *unused) {
         while (uart_irq_update(uart_pipe_dev)
                   && uart_irq_is_pending(uart_pipe_dev)) {
                ...
         }

uart_irq_update() is always 1 and uart_irq_is_pending()
is also always 1 (at least in case of stm32):
         return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
                     LL_USART_IsActiveFlag_TXE(UartInstance));

So possible solutions as I can see are:
1) Use uart_irq_rx_ready() instead of  uart_irq_is_pending() in
    while() in uart_pipe.c
 2) Change uart_stm32_irq_is_pending() to return only RNXE -
   however other drivers also return RXE || TXE
3) Mask TXE as Michael suggested that is actually (2).

> Erwan
>
> On 30 November 2017 at 01:07, Dmitry Shmidt via Zephyr-devel
> <zephyr-devel@...ect.org> wrote:
>>
>> Hello,
>>
>> In uart_pipe.c code:
>> static void uart_pipe_isr(struct device *unused)
>> {
>>         ARG_UNUSED(unused);
>>
>>         while (uart_irq_update(uart_pipe_dev)
>>                   && uart_irq_is_pending(uart_pipe_dev)) {
>> ...
>> }
>>
>> uart_irq_update() is returning 1 and
>> uart_irq_is_pending() is always TRUE for stm32, because
>> despite RXNE is cleared, TXE is always 1.
>> static int uart_stm32_irq_is_pending(struct device *dev)
>> {
>>         USART_TypeDef *UartInstance = UART_STRUCT(dev);
>>
>>         return (LL_USART_IsActiveFlag_RXNE(UartInstance) ||
>>                    LL_USART_IsActiveFlag_TXE(UartInstance));
>>
>> TXE is always 1 probably by design because poll_out is working
>> properly:
>> static unsigned char uart_stm32_poll_out(struct device *dev,
>>
>> unsigned char c)
>> {
>>         USART_TypeDef *UartInstance = UART_STRUCT(dev);
>>
>>         /* Wait for TXE flag to be raised */
>>         while (!LL_USART_IsActiveFlag_TXE(UartInstance))
>>                 ;
>>
>> Please advise what is the right way to fix this issue:
>> 1) Use uart_irq_rx_ready() instead of  uart_irq_is_pending() in
>> while() in uart_pipe.c
>> 2) Change uart_stm32_irq_is_pending() to return only RNXE -
>> however other drivers also return RXE || TXE
>> 3) Clear TXE during input processing
>>
>> Thanks,
>> Dmitry
>> _______________________________________________
>> Zephyr-devel mailing list
>> Zephyr-devel@...ct.org
>> https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel
>
>
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Vikrant More wrote:
But as per my testing, zephyr publishing reliability is not good even if I
call bt_mesh_model_publish() from thread which wakes up on interrupt.
This is not really useful information without some more details. What
Publish Retransmit and Network Transmit states does the Nordic SDK use?
What are the values of these states on the Zephyr side? There are many
parameters that can be fine-tuned which influence message delivery
reliability, and these have very little to do with the actual
implementation and a lot to do with how you've configured your nodes.
Also note that having GATT connections inevitably lowers the duty-cycle
on the advertising bearer, so your nodes are much more likely to loose
packets in that case.

Johan


Zephyr IPSP sample crashes and ble controller crashes (IPv6 over BLE)

Priyanka Rawat <priyanka.rawat@...>
 

Hello

My test set up for IPv6 over BLE is following :

At one end : Two boards frdm-kw41z and frdm-k64f are stacked together.
kw41z (flashed with hci_blackbox firmware) is ble controller with k64f as ble host (flashed with zephyr sample IPSP).

At the other end: Second kw41z (flashed with hci_blackbox firmware) is ble controller attached to Linux host. 


[Kw41z  (ble controller)+ k64f (zephyr IPSP)] <---------->[Kw41z (ble controller)+Linux host]

Issue with testing IPv6 over BLE :

Once the BLE connection is established, within few seconds BLE controller gets disconnected.
Either zephyr (recent master branch) crashes or BLE controller crashes or both. Often it is BLE controller that gets disconnected within few seconds.
Restarting zephyr might enable establishing the connection once again, but then ble controller goes down immediately.

After that, I should disconnect the boards and connect again (via usb connection) in order to set up the ble connection again.

While on Zephyr side, it always prints connection handle 32
On Linux side, the first time connection handle is 32, afterwards it is different (handle 65, 128 etc.,) as shown with "hcitool conn".
btmon log shows for specific handle : remote user terminated connection or connection terminated by local host

On Linux PC
--------------
$ sudo hciattach ttyACMx any 115200 noflow sleep
Device setup complete

$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 32 state 1 lm MASTER


$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 65 state 8 lm MASTER

$ sudo hcitool conn

Connections:


$ sudo hcitool lescan

LE Scan ...

00:04:9F:00:00:15 (unknown)

00:04:9F:00:00:15 Test IPSP node

04:52:C7:64:6C:65 (unknown)


$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 96 state 1 lm MASTER

$ sudo hcitool conn

Connections:

$ sudo hcitool conn

Connections:

< LE 00:04:9F:00:00:15 handle 128 state 1 lm MASTER

$ sudo hcitool conn

Connections:



Zephyr (IPSP)
--------------------
During that very short span of connection, ping does not pass, there is a ping time out and then ble controller goes down.

And it prints error

[bt] [ERR] read_payload: Not enough space in buffer


net> iface

Interface 0x2000a020 (Bluetooth)
================================
Link addr : 00:04:9F:00:00:15
MTU       : 1280
IPv6 unicast addresses (max 3):
        2001:db8::1 manual preferred infinite
        fe80::4:9fff:fe00:15 autoconf preferred infinite
IPv6 multicast addresses (max 2):
        ff84::2
        ff02::1
IPv6 prefixes (max 2):
        <none>
IPv6 hop limit           : 64
IPv6 base reachable time : 30000
IPv6 reachable time      : 9178
IPv6 retransmit timer    : 0
net> ping 2001:db8::2
Sent a ping to 2001:db8::2
[bt] [DBG] bt_l2cap_chan_send: (0x20001210) chan 0x20009bcc buf 0x20006db4 len 57
[bt] [DBG] l2cap_chan_create_seg: (0x20001210) ch 0x20009bcc seg 0x20006bf8 len 59
[bt] [DBG] l2cap_chan_le_send: (0x20001210) ch 0x20009bcc cid 0x0040 len 59 credits 3
[bt] [DBG] bt_l2cap_send_cb: (0x20001210) conn 0x200008d4 cid 64 len 59
[bt] [DBG] bt_conn_send_cb: (0x20001210) conn handle 32 buf len 63 cb 0x00000000
[bt] [DBG] l2cap_chan_le_send_sdu: (0x20001210) ch 0x20009bcc cid 0x0040 sent 57 total_len 57
[bt] [DBG] bt_conn_process_tx: (0x200006f8) conn 0x200008d4
[bt] [DBG] send_buf: (0x200006f8) conn 0x200008d4 buf 0x20006bf8 len 63
[bt] [DBG] send_frag: (0x200006f8) conn 0x200008d4 buf 0x20006bf8 len 63 flags 0x00
[bt] [DBG] bt_conn_notify_tx: (0x200006f8) conn 0x200008d4
[bt] [DBG] add_pending_tx: (0x200006f8) conn 0x200008d4 cb 0x00000000
[bt] [DBG] bt_conn_prepare_events: (0x200006f8)
[bt] [DBG] bt_conn_prepare_events: (0x200006f8) Adding conn 0x200008d4 to poll list
Ping timeout

btmon log shows for specific handle : remote user terminated connection or connection terminated by local host

$ sudo btmon

< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                             [hci0] 56.603853
        Handle: 32
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.605669
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 56.623140
        Num handles: 1
        Handle: 32
        Count: 0
> HCI Event: Disconnect Complete (0x05) plen 4                                                                             [hci0] 56.623895
        Status: Success (0x00)
        Handle: 32
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2



$ sudo btmon
Bluetooth monitor ver 5.37
= New Index: 00:60:37:00:00:16 (BR/EDR,UART,hci0)                                                                           [hci0] 0.420344
= Open Index: 00:60:37:00:00:16                                                                                             [hci0] 0.420346
= Index Info: 00:60:37:00:00:16 (NXP Semiconductors (formerly Philips Semiconductors))                                      [hci0] 0.420347
> HCI Event: LE Meta Event (0x3e) plen 19                                                                                  [hci0] 25.087469
      LE Connection Complete (0x01)
        Status: Success (0x00)
        Handle: 32
        Role: Master (0x00)
        Peer address type: Public (0x00)
        Peer address: 00:04:9F:00:00:15 (Freescale Semiconductor)
        Connection interval: 18.75 msec (0x000f)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 32000 msec (0x0c80)
        Master clock accuracy: 0x00
< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                           [hci0] 25.087749
        Handle: 32
@ Device Connected: 00:04:9F:00:00:15 (1) flags 0x0000
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 25.090858
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 12                                                                                  [hci0] 25.160087
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 32
        Features: 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
< ACL Data TX: Handle 32 flags 0x00 dlen 7                                                                                 [hci0] 25.160299
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 25.197003
        Num handles: 1
        Handle: 32
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                  [hci0] 25.216210
      LE Data Length Change (0x07)
        Handle: 32
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> ACL Data RX: Handle 32 flags 0x02 dlen 7                                                                                 [hci0] 25.291092
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 65
< ACL Data TX: Handle 32 flags 0x00 dlen 11                                                                                [hci0] 25.291176
      ATT: Read By Group Type Request (0x10) len 6
        Handle range: 0x0001-0xffff
        Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 25.309459
        Num handles: 1
        Handle: 32
        Count: 1
< HCI Command: LE Create Connection (0x08|0x000d) plen 25                                                                  [hci0] 56.599500
        Scan interval: 2.500 msec (0x0004)
        Scan window: 2.500 msec (0x0004)
        Filter policy: White list is not used (0x00)
        Peer address type: Public (0x00)
        Peer address: 00:04:9F:00:00:15 (Freescale Semiconductor)
        Own address type: Public (0x00)
        Min connection interval: 18.75 msec (0x000f)
        Max connection interval: 18.75 msec (0x000f)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
        Min connection length: 0.625 msec (0x0001)
        Max connection length: 0.625 msec (0x0001)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.603808
      LE Create Connection (0x08|0x000d) ncmd 1
        Status: Success (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3                                                                             [hci0] 56.603853
        Handle: 32
        Reason: Remote User Terminated Connection (0x13)
> HCI Event: Command Status (0x0f) plen 4                                                                                  [hci0] 56.605669
      Disconnect (0x01|0x0006) ncmd 1
        Status: Success (0x00)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                     [hci0] 56.623140
        Num handles: 1
        Handle: 32
        Count: 0
> HCI Event: Disconnect Complete (0x05) plen 4                                                                             [hci0] 56.623895
        Status: Success (0x00)
        Handle: 32
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2

> HCI Event: Disconnect Complete (0x05) plen 4                                                                            [hci0] 495.817382
        Status: Success (0x00)
        Handle: 96
        Reason: Connection Terminated By Local Host (0x16)
@ Device Disconnected: 00:04:9F:00:00:15 (1) reason 2


< HCI Command: LE Read Remote Used Features (0x08|0x0016) plen 2                                                          [hci0] 559.455648
        Handle: 128
@ Device Connected: 00:04:9F:00:00:15 (1) flags 0x0000
> HCI Event: Command Status (0x0f) plen 4                                                                                 [hci0] 559.458269
      LE Read Remote Used Features (0x08|0x0016) ncmd 1
        Status: Success (0x00)

> HCI Event: LE Meta Event (0x3e) plen 12                                                                                 [hci0] 559.552125
      LE Read Remote Used Features (0x04)
        Status: Success (0x00)
        Handle: 128
        Features: 0xff 0x00 0x00 0x00 0x00 0x00 0x00 0x00
          LE Encryption
          Connection Parameter Request Procedure
          Extended Reject Indication
          Slave-initiated Features Exchange
          LE Ping
          LE Data Packet Length Extension
          LL Privacy
          Extended Scanner Filter Policies
< ACL Data TX: Handle 128 flags 0x00 dlen 7                                                                               [hci0] 559.552334
      ATT: Exchange MTU Request (0x02) len 2
        Client RX MTU: 517
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 559.589004
        Num handles: 1
        Handle: 128
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                 [hci0] 559.608138
      LE Data Length Change (0x07)
        Handle: 128
        Max TX octets: 251
        Max TX time: 2120
        Max RX octets: 251
        Max RX time: 2120
> ACL Data RX: Handle 128 flags 0x02 dlen 7                                                                               [hci0] 559.683143
      ATT: Exchange MTU Response (0x03) len 2
        Server RX MTU: 65
< ACL Data TX: Handle 128 flags 0x00 dlen 11                                                                              [hci0] 559.683325
      ATT: Read By Group Type Request (0x10) len 6
        Handle range: 0x0001-0xffff
        Attribute group type: Primary Service (0x2800)
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 559.701758
        Num handles: 1
        Handle: 128
        Count: 1
> HCI Event: LE Meta Event (0x3e) plen 11                                                                                 [hci0] 564.727345
      LE Remote Connection Parameter Request (0x06)
        Handle: 128
        Min connection interval: 30.00 msec (0x0018)
        Max connection interval: 50.00 msec (0x0028)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
< HCI Command: LE Remote Connection Parameter Request Reply (0x08|0x0020) plen 14                                         [hci0] 564.727418
        Handle: 128
        Min connection interval: 30.00 msec (0x0018)
        Max connection interval: 50.00 msec (0x0028)
        Connection latency: 0x0000
        Supervision timeout: 32000 msec (0x0c80)
        Min connection length: 0.000 msec (0x0000)
        Max connection length: 0.000 msec (0x0000)
@ New Conn Param: 00:04:9F:00:00:15 (1) hint 1 min 0x0018 max 0x0028 latency 0x0000 timeout 0x0c80
> HCI Event: Command Complete (0x0e) plen 6                                                                               [hci0] 564.731202
      LE Remote Connection Parameter Request Reply (0x08|0x0020) ncmd 1
        Status: Success (0x00)
        Handle: 128
> HCI Event: LE Meta Event (0x3e) plen 10                                                                                 [hci0] 564.971598
      LE Connection Update Complete (0x03)
        Status: Success (0x00)
        Handle: 128
        Connection interval: 30.00 msec (0x0018)
        Connection latency: 0.00 msec (0x0000)
        Supervision timeout: 32000 msec (0x0c80)
< ACL Data TX: Handle 128 flags 0x00 dlen 18                                                                              [hci0] 577.871547
      LE L2CAP: LE Connection Request (0x14) ident 1 len 10
        PSM: 35 (0x0023)
        Source CID: 64
        MTU: 1280
        MPS: 230
        Credits: 10
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 577.902129
        Num handles: 1
        Handle: 128
        Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 18                                                                              [hci0] 578.113503
      LE L2CAP: LE Connection Response (0x15) ident 1 len 10
        Destination CID: 64
        MTU: 1280
        MPS: 65
        Credits: 20
        Result: Connection successful (0x0000)
< ACL Data TX: Handle 128 flags 0x00 dlen 46                                                                              [hci0] 578.119173
      Channel: 64 len 42 [PSM 35 mode 0] {chan 2}
        28 00 79 4b 00 16 3a 00 05 02 00 00 01 00 8f 00  (.yK..:.........
        6f 74 00 00 00 01 04 00 00 00 ff 02 00 00 00 00  ot..............
        00 00 00 00 00 01 ff 00 00 16                    ..........      
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.142511
        Num handles: 1
        Handle: 128
        Count: 1
< ACL Data TX: Handle 128 flags 0x00 dlen 50                                                                              [hci0] 578.211240
      Channel: 64 len 46 [PSM 35 mode 0] {chan 2}
        2c 00 7b 3b 3a 01 88 00 b2 32 20 00 00 00 fe 80  ,.{;:....2 .....
        00 00 00 00 00 00 02 60 37 ff fe 00 00 16 02 02  .......`7.......
        00 60 37 ff fe 00 00 16 00 00 00 00 00 00        .`7...........  
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.232753
        Num handles: 1
        Handle: 128
        Count: 1
> ACL Data RX: Handle 128 flags 0x02 dlen 39                                                                              [hci0] 578.236748
      Channel: 64 len 35 [PSM 35 mode 0] {chan 2}
        21 00 7b 49 3a 02 01 ff 00 00 15 87 00 0c 2c 2a  !.{I:.........,*
        52 a7 7a fe 80 00 00 00 00 00 00 00 04 9f ff fe  R.z.............
        00 00 15                                         ...             
< ACL Data TX: Handle 128 flags 0x00 dlen 39                                                                              [hci0] 578.263150
      Channel: 64 len 35 [PSM 35 mode 0] {chan 2}
        21 00 7b 49 3a 02 01 ff 00 00 16 87 00 43 9b 00  !.{I:........C..
        00 00 00 fe 80 00 00 00 00 00 00 02 60 37 ff fe  ............`7..
        00 00 16                                         ...             
> HCI Event: Number of Completed Packets (0x13) plen 5                                                                    [hci0] 578.292505
        Num handles: 1
        Handle: 128
        Count: 1


--------------------------------------------------------

samples/bluetooth/ipsp$ prj.conf

CONFIG_BT=y
CONFIG_BT_DEBUG_LOG=y
CONFIG_BT_SMP=y
CONFIG_BT_PERIPHERAL=y
CONFIG_BT_L2CAP_DYNAMIC_CHANNEL=y
CONFIG_BT_DEVICE_NAME="Test IPSP node"
CONFIG_NETWORKING=y
CONFIG_NET_IPV6=y
CONFIG_NET_IPV4=n
CONFIG_NET_UDP=y
CONFIG_NET_TCP=y
CONFIG_TEST_RANDOM_GENERATOR=y
CONFIG_NET_LOG=y
CONFIG_NET_L2_BT=y
CONFIG_NET_DEBUG_L2_BT=y
CONFIG_SYS_LOG_SHOW_COLOR=y
CONFIG_INIT_STACKS=y
CONFIG_NET_STATISTICS=y
CONFIG_NET_PKT_RX_COUNT=10
CONFIG_NET_PKT_TX_COUNT=10
CONFIG_NET_BUF_RX_COUNT=20
CONFIG_NET_BUF_TX_COUNT=20
CONFIG_NET_IF_UNICAST_IPV6_ADDR_COUNT=3
CONFIG_NET_IF_MCAST_IPV6_ADDR_COUNT=2
CONFIG_NET_MAX_CONTEXTS=6

CONFIG_NET_SHELL=y
CONFIG_BT_SHELL=y

CONFIG_NET_APP_SETTINGS=y
CONFIG_NET_APP_MY_IPV6_ADDR="2001:db8::1"
CONFIG_NET_APP_PEER_IPV6_ADDR="2001:db8::2"
CONFIG_NET_APP_BT_NODE=y

CONFIG_NET_L2_ETHERNET=n
CONFIG_ETH_MCUX=n
CONFIG_ETH_MCUX_0=n

#CONFIG_BT_DEBUG_HCI_DRIVER=y
#CONFIG_BT_DEBUG_HCI_CORE=y

CONFIG_BT_PRIVACY=n
#CONFIG_BT_DEBUG=y
#CONFIG_BT_DEBUG_HCI_CORE=n
CONFIG_BT_DEBUG_CONN=y
CONFIG_BT_DEBUG_KEYS=y
CONFIG_BT_DEBUG_L2CAP=y
CONFIG_BT_DEBUG_SMP=y
CONFIG_BT_DEBUG_SDP=y


Thanks

Priyanka


Re: How to use "mesh" and "mesh_demo" under ./zephyr/sample/bluetooth?

Kai Ren
 

Hi Johan,

 

Thanks for your supporting and answer!

Currently, I try to use ./sample/Bluetooth/mesh for demo. I used “Silicon Labs Bluetooth mesh” App to provision my board, my board is Nordic pca10028, the zephyr firmware is built by github master and I just git pull today.

Attached is prj.conf configuration.

The phenomenon is that I couldn’t use Silicon Labs App to provision pca10028 board, I can use the App to scan, find the board, hit “provision” button, after that, nothing could happen, Demo Network didn’t have any device which was provisioned. Below is part of console output. I just want to know what is wrong about my configuration.

 

[bt] [DBG] send_pub_key: (0x20001d00) Local Public Key: 4d777e2aaed12f32d8044f8bf1a94f55fc18e62f5518def83349bac7eacbac7ae52c67fa88d251db62b7caab8484b346c9b833498bf64268739f0950df12b9f9

[bt] [DBG] proxy_segment_and_send: (0x20001d00) conn 0x200004c4 type 0x03 len 65: 037aaccbeac7ba4933f8de18552fe618fc554fa9f18b4f04d8322fd1ae2a7e774df9b912df50099f736842f68b4933b8c946b38484abcab762db51d288fa672c

[bt] [DBG] proxy_send: (0x20001d00) 66 bytes: 03037aaccbeac7ba4933f8de18552fe618fc554fa9f18b4f04d8322fd1ae2a7e774df9b912df50099f736842f68b4933b8c946b38484abcab762db51d288fa67

Kernel stacks:

main      (real size 512):      unused 212      usage 300 / 512 (58 %)

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

interrupt (real size 2048):     unused 1664     usage 384 / 2048 (18 %)

workqueue (real size 2048):     unused 1732     usage 316 / 2048 (15 %)

tx stack (real size 940):       unused 480      usage 460 / 940 (48 %)

[bt] [DBG] proxy_disconnected: (0x20001d00) conn 0x200004c4 reason 0x13

[bt] [DBG] bt_mesh_pb_gatt_close: (0x20001d00) conn 0x200004c4

[bt] [DBG] bt_mesh_proxy_adv_stop: (0x200007e4) adv_enabled 0

[bt] [DBG] bt_mesh_proxy_adv_start: (0x200007e4) 

[bt] [DBG] prov_dh_key_cb: (0x20000370) 0x20002450

[bt] [DBG] prov_dh_key_cb: (0x20000370) DHkey: 2a52e6f2c2b31593e5cbef3aa579dfab73c1e3756e699868a90bf1aa22b7eb7e

ecc stack (real size 1324):     unused 400      usage 924 / 1324 (69 %)

 

 

Regards,

Kai

 

 

 

On 25/11/2017, 12:27 AM, "Johan Hedberg" <johan.hedberg@...> wrote:

 

    Hi Kai,

   

    On Fri, Nov 24, 2017, Kai Ren wrote:

    > I’m using Zephyr

    > v1.10.0-rc1<https://github.com/zephyrproject-rtos/zephyr/releases/tag/v1.10.0-rc1>

    > and I can build “mesh” and “mesh_demo” on my Windows laptop for BBC

    > micro:bit and nRF52 PCA10040.

    > I want to use it for testing like provisioning, but I don’t know how

    > to use it because I can’t find any description

    > here<http://docs.zephyrproject.org/samples/bluetooth/bluetooth.html>,

    > could you please share some information about “how to use”?

   

    The mesh_demo app doesn't do external provisioning, rather it has

    hard-coded addresses and keys (the address is set using a NODE_ADDR

    build-time define).

   

    The mesh app, on the other hand, should come up sending out

    unprovisioned beacons using the UUID "dddd<zeroes...>" that you can then

    use to start provisioning it. If I remember right, the default

    configuration used PB-ADV, but there's an alternative configuration file

    for PB-GATT as well.

   

    I'd also recommend familiarizing yourself with the new mesh_shell app,

    that provides an interactive shell for mesh. You can find it under

    tests/bluetooth/mesh_shell. However, for this one I'd recommend going

    with the latest master branch rather than rc1, since there has been many

    recent fixes to it. This is the app that will get you the furthest e.g.

    if you want to run PTS tests against Zephyr. To make the shell send out

    unprovisioned beacons you'd first run "init" and after that, depending

    on which provisioning bearer you want, you'd run "pb-gatt on" or "pb-adv

    on". The "help" command will give you a list of available commands. Note

    however that it's in practice assuming familiarity with technical

    details of the foundation models (configuration & health).

   

    One thing to note about mesh_shell is that you wont be able to fit it on

    the 16k RAM micro:bit since it enables almost all features as well as

    some basic debug logging. On the nRF52 it should work fine though.

   

    Johan

   


Complete Sample Demo for BluetoothMesh like Nordic Semiconductor "Light_Switch"

Vikrant More <vikrant8051@...>
 

Hello,

I need simple clone of of "Light_Switch" demo (part of nordic semiconductor mesh SDK) using Zephyr.
In that demo, we can control Led1 on Servers using publishing data from client. Reliability is 100% even entire demo is based on only ADV-Bearer.
They used one client & 3 Servers. Client itself acts like provisioner.

Unfortunately, Nordic uses only ADV-Bearer & so we can't use available Silicon Labs Mesh App as provisioner.

So I shift to Zephyr since at least I can test working of Mesh using Provisioner APP.

But as per my testing, zephyr publishing reliability is not good even if I call bt_mesh_model_publish() from thread which wakes up on interrupt.

I want to publish 0 and 1 (toggle) after pressing button on one device to all other available nodes in vicinity. (individually using Unicast addresses & for many using Group address  )

So please release such full working demo like Nordic using Zephyr OS.
 
Or help me in details so that I can release behalf on Zephyr Community.

Thank You!!


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Johan Hedberg wrote:
On Tue, Dec 05, 2017, Vikrant More wrote:
I applied your recent patch (that is https://github.com/
zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App)
if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.
Are you talking about adv-adv relaying or GATT-adv relaying (or
vice-versa)? Steve seemed to confirm that the current code works as it
should.
I took a second look at the logic in bt_mesh_net_relay() and indeed it
was still buggy. Thanks for catching this. The following pull request
(which I'm still doing a bit of testing on) should fix the issue:

https://github.com/zephyrproject-rtos/zephyr/pull/5275

Johan


Re: Mesh: mesh_shell: Unexplained warning from proxy.c:net_id_adv()

Johan Hedberg
 

Hi Steve,

On Mon, Dec 04, 2017, Johan Hedberg wrote:
On Mon, Dec 04, 2017, Steve Brown wrote:
If I issue an ident w/ gatt-proxy off, it completes without a warning.

If I issue an ident w/ gatt-proxy on, it completes without a warning.

If I issue an ident w/ gatt-proxy on and a connection from meshctl has
been established to the config service, it gives the warning "Failed to
advertise using Network ID (err -5)".

I've attached a fairly verbose log. The warning is at the end.

Can somebody explain what's going on?
I believe this is proxy.c trying to restart (connectable) advertising,
however since you're already maxed out at the number of supported
connections the controller throws you an error saying it can't do
connectable advertising at the moment. This should generally be a benign
warning, since the right type of advertising will be resumed eventually
when the connection gets disconnected.

Increasing CONFIG_BT_MAX_CONN should help avoid this warning coming too
easily, but the downside is increased runtime memory consumption.

Yet another option would be for proxy.c to do connection counting and
not attempt connectable advertising if it knows we're at MAX_CONN
already.
I went ahead and implemented this last option, since it was so simple to
do. It's the last patch in this pull request:

https://github.com/zephyrproject-rtos/zephyr/pull/5269

Johan


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Vikrant,

On Tue, Dec 05, 2017, Johan Hedberg wrote:
Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs
Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte
of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".
Are you sure nRF connect isn't juts holding on to cached GATT database
information. When provisioning is complete Zephyr will remove the
provisioning service and replace it with the GATT proxy service. This
means that the GATT Proxy service will likely get the same attribute
handle values as the provisioning service. The Zephyr GATT server will
send out appropriate service changed indications for this, but if the
client doesn't support this it might get confused (thinking the old
service is there even though it has actually been replaced with another
one). You'd probably need to find a way to force re-discovery of
services (possibly by disconnecting & reconnecting).
For the record, I just did a quick test with the LigthBlue app (similar
to nRFConnect) and it correctly shows that the Provisioning service
(UUID 0x1827) gets replaced by the GATT Proxy service (UUID 0x1828)
after provisioning.

Johan


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Johan Hedberg
 

Hi Vikrant,

Please try to avoid top-posting, especially if the existing thread is
using inline quoting.

On Tue, Dec 05, 2017, Vikrant More wrote:
I applied your recent patch (that is https://github.com/
zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App)
if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.
Are you talking about adv-adv relaying or GATT-adv relaying (or
vice-versa)? Steve seemed to confirm that the current code works as it
should.

Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs
Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte
of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".
Are you sure nRF connect isn't juts holding on to cached GATT database
information. When provisioning is complete Zephyr will remove the
provisioning service and replace it with the GATT proxy service. This
means that the GATT Proxy service will likely get the same attribute
handle values as the provisioning service. The Zephyr GATT server will
send out appropriate service changed indications for this, but if the
client doesn't support this it might get confused (thinking the old
service is there even though it has actually been replaced with another
one). You'd probably need to find a way to force re-discovery of
services (possibly by disconnecting & reconnecting).

Johan


Re: [Zephyr-users] samples/basic/button code not working on nrf52840

Laurence Pasteau
 

Hi,


I think you have maybe the answer here :

https://github.com/zephyrproject-rtos/zephyr/issues/4008


Does it help you ?


Regards,

Laurence


De : zephyr-users-bounces@... <zephyr-users-bounces@...> de la part de ashish.shukla@... <ashish.shukla@...>
Envoyé : mardi 5 décembre 2017 05:29
À : Johan Hedberg; zephyr-users@...; zephyr-devel@...
Objet : [Zephyr-users] samples/basic/button code not working on nrf52840
 
Hi,

I'm trying to work with button interrupt available in samples/basic/button example on nrf52840. I'm unable to figure out why it isn't working.
Code compiles successfully but interrupt is never enabled. Any help would be appreciated. 


--
Warm regards,
Ashish Shukla
Jr. Embedded Engineer
Research & Development


Please consider the environment before printing this e-mail or its attachments.

Disclaimer: The information contained herein (including any accompanying documents) is confidential and is intended solely for the addressee(s). If you have erroneously received this message, please immediately delete it and notify the sender. Also, if you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this message or any accompanying document is strictly prohibited and is unlawful. The organization is not responsible for any damage caused by a virus or alteration of the e-mail by a third party or otherwise. The contents of this message may not necessarily represent the views or policies of Corvi


Re: mesh: relay traffic when relay state is 0x02 (not supported)

Vikrant More <vikrant8051@...>
 

I applied your recent patch (that is https://github.com/zephyrproject-rtos/zephyr/pull/5243 )

But it is still relaying packet (after Relay is OFF using Silicon Labs App) if destination address is Group Address.
It does not relay only when destination Address is self Unicast Address.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Second thing is,

As I previously mentioned that , even after provisiong using Silicon Labs Mesh APP, I'm still able to access Mesh Proxy Service
using Nordic Semiconductor nRFConnect App. For ref. plz see attached images.

Plus NODE accepts data from that service. To check that I send some 1 byte of random data to it & serial terminal of Node gives me
error as "Dropping too short message packet".


Please re-check & confirm this.
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////



On Sun, Dec 3, 2017 at 7:42 PM, Vikrant More <vikrant8051@...> wrote:
Sir I'm talking about this(attached image) ON/OFF setting which available during configuration of Device.

As per my observation, whatever we set here doesn't get reflected at device side. Means if we turn off relay, NODE still relaying the received packets.

>>The GATT service should be gone. After provisioning, if you disconnect,
>>reconnect, and are still able to discover the provisioning service UUID
>>in the GATT database, then that's a bug.


After provisioning, Silicon Labs Mesh App is not able to discover the NODEs. But it get detected in nRFConnect App (App provided by Nordic Semiconductor) as unknown device (not as Zephyr). We can easily connect with it & easily access Mesh Provising Service using the same App.

When I send some random data via it, on terminal of NODE we get error as "message is too short". Means NODE accepts data from any device. 

If possible please try all my observations using SiliconLabs App & nrf52840_pca10056 board.

Correct me if I'm wrong somewhere.

Thank You !!

On Dec 3, 2017 2:00 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Sun, Dec 03, 2017, Vikrant More wrote:
> If I configured Relay OFF/ Proxy Off using Silicon Labs Bluetooth Mesh App
> that does not change anything in reality.  If Relay is ON as per firmware
> then it remains ON.

What do you mean by this? That the state value remains 0x01 or that the
node keeps relaying regardless of the value? If you have GATT Proxy
enabled then you're observing the same thing as Steve reported, and this
should get fixed by my latest pull request.

> Plus even after provisioning, I can connect to #MeshProvisioningService on
> NODE using #nRFconnect App and also able to send data to it.

The GATT service should be gone. After provisioning, if you disconnect,
reconnect, and are still able to discover the provisioning service UUID
in the GATT database, then that's a bug.

Johan


4261 - 4280 of 8046