Date   

Re: Choosing Tx Buffers in BLE stack

pawel.dunaj@...
 

Hi,

Whatever Zephyr is doing I don't think Win should crash. I expect this is a bug in the OS or the driver. You can try MS support, maybe they can help. It should simply reject the data (that will probably not help you much as you may miss an information about key release).

At first I expected you are not sending normal HID data but instead put some custom data in the HID report, but you state that you work on a keyboard. Are you using zephyr hid sample? How is your report defined? How much data are you sending with each notification?

Zephyr will block when there is no buffer available to add the notification data too. If data is not picked fast enough by the host (i.e. connection is slow) pipeline of data waiting to be served will build up. It is up to your application to ensure the valid data flow. For that you can check optional callback added to Zephyr recently.

As for limiting the number of data sent with each connection interval, you are doing that by correctly setting up the report map and sending data according to it. Are you doing that? (Maybe system receives too much data compared to what was stated in the map and crash?)

To limit the data sent with each interval you can try changing MTU, however I don't think this is the problem.

Thanks,
Pawel


Re: Choosing Tx Buffers in BLE stack

dhguja@gmail.com
 

Hi All,
      With regards to my previous problems I have some basic questions to understand this problem. 
By increasing the Tx Buffers i increased the number packets transmitted per connection interval. 
Even though this increased my data transfer speed i faced compatibility issue with windows HID driver 
crashing in the middle of transmission. I read that Android and iOS systems sometimes have a limit on 
the number of packets transmitted per connection interval time. May be for windows too there may be 
some limit  on this factor. when i checked the HCI logs i see that almost all the HID characters are sent 
with in one connection interval for my device. 

Is it possible to configure this factor in zephyr either directly or indirectly?
(or) 
Should application layer handle these delays?

Regards,
Dhananjay G J



On Fri, Sep 21, 2018 at 3:42 PM dhananjay gj <dhguja@...> wrote:
Hi,
    Thanks for the reply. Sorry if there is some confusion regarding the crash on windows. 

I will explain more elaborately below what i am trying to achieve & what i debugged till now.

I am working on BLE based barcode scanner which will send the data via HID over GATT profile. I am using nRF52840 
device and Zephyr 1.13 with default connection interval parameters. With the default Tx buffer numbers provided in zephyr
the characters are sent to peer devices very slowly. We can literally see that characters are printed one by one. When i checked
the HCI timestamps using btmon i see that 1 character is sent every connection interval time(around 45 ms ). 

To remove the bottleneck on Tx buffers i increased Maximum number of pending TX buffers (3) , Number of Tx buffers(3).
I see that characters are sent instantly now (within one connection interval or even less than 10ms). The improvement in speed
is seen only when i change both of these parameters from the default values.

Now with this new config changes related to Tx buffers my application works fast as expected in Android, iOS, Linux systems. 
But on windows 10 system after two or three scans 'Windows' HID driver crashes probably due to buffer overflow from sending the 
data so fast. I checked the windows log and i see that "A command sent to the adapter has timed out. The adapter did not respond".
The behavior seen is that characters are not accepted anymore and the last character that is sent to windows is printed continuously 
until the connection is closed. On the zephyr side, the bt_gatt_notify API is blocked until this time and then returns with error. 
I also checked the connection interval used with Windows 10 system as 40 ms.

I also changed different buffer numbers to know the behavior but this just changes the time when this crash in windows occurs again. 
I also checked with some commercial devices that have similar application of using HID profile to send data and it also uses buffering
to speed up. One thing i noticed in commercial device is for every 10 characters sent there is some delay equal to max connection 
interval time. But in case of my application using zephyr there is just 1 delay with connection interval for even up to 40 characters that are 
sent.

In order to control the speed of buffering i tried changing different buffer numbers but with no luck or information on how to proceed
further. If i know how to calculate or more information on these i can try to control the speed of my application by using buffer numbers or 
delays like i saw in other commercial devices. It would be helpful even if i had to look for something else in BLE specification or Zephyr.

Thanks very much for the help.

Regards,
Dhananjay G J











On Fri, Sep 21, 2018 at 1:20 PM Von Dentz, Luiz <luiz.von.dentz@...> wrote:
Hi,

I guess that is because with more buffer one can queue more data and
is less affected by the speed in which the controller acknowledge
their transmissions, obviously this increase the footprint but it is
the usual trade of size for speed. Btw, if the improvement is
substantial maybe we should have 3 by default, though we need to
figure if the crash on windows is due to some misbehaviour on our side
when are operating with more buffers.

On Fri, Sep 21, 2018 at 1:58 PM, Cufi, Carles <Carles.Cufi@...> wrote:
>
> Hi there,
>
> Copying a few people to this thread.
>
> Carles
>
> ________________________________
> From: devel@... <devel@...> on
> behalf of dhguja@... <dhguja@...>
> Sent: Thursday, September 20, 2018 11:56 AM
> To: devel@...
> Subject: [Zephyr-devel] Choosing Tx Buffers in BLE stack
>
> Hello,
>       I am working on a BLE HID keyboard application using zephyr 1.13.
>
> I was playing around with Tx buffers (specifically Maximum number of pending
> TX buffers, Number of Tx buffers).
> With default buffer settings the characters were transmitted very slowly due
> to small number of buffers. But as soon as
> i increased it to 3 pending buffers and 3 Tx buffers i saw significant
> improvement in the speed of characters transmitted.
> My question is how to choose the buffer values for this?.
>
> The reason is currently i face a compatibility problem with my HID
> application, where it works fine in Linux, Android, iOS devices
> with increased number of buffers, but crashes on windows system. When i
> debugged the HCI log (from btmon) i saw that with
> increased buffers, characters are sent very quickly on the order of 500 us
> for each character. This causes the data (of 20 characters)
> to be transmitted within one or two connection intervals. Maybe this causes
> some overflow in windows systems. I would like to know
> what are the implications of choosing a number of Tx buffers and pending
> buffers.
>
> It will be helpful if anyone can tell how to choose the number of Tx
> buffers? or even point to some direction in the BLE specification?
>
> Thank you,
> Dhananjay G J


Re: Compilers working on Zephyr

pehe@...
 

Hi Flavio

 

Oticon is using a compiler different from those in the SDK.

Front-end is clang, but everything else is proprietary.

 

Problems we are facing:

 * C99 issues (mostly solved now)

 * Cmake being hardcoded for GNU (we have patches that we want to PR - but they have to be cleaned up)

 * Linker. (Not compatible with GNU LD, and more feature constrained).

 * Unaligned access, big-endian.


br
  Peter


Re: Compilers working on Zephyr

Sebastian Boe
 

This is a known hole in our documentation.

To discover toolchains that have in-tree integrations see the contents of zephyr/cmake/toolchain.

Toolchains that are not integrated use CROSS_COMPILE, but using CROSS_COMPILE will only work for certain types of toolchains and certain types of Zephyr configurations.

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of Flavio Ceolin <flavio.ceolin@intel.com>
Sent: Saturday, September 29, 2018 12:01:04 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Compilers working on Zephyr

Hi,

Guys I'm trying to have a list of supported compilers on Zephyr, but in
our wiki just mention about 3rd-party compilers but don't mention any
other than GNU ARM compiler.

If you are using a compiler different from our SDK, can you tell me so I
can catalog it. If you're just trying to use other compiler, please tell
me which problems you are facing.

Regards,
Flavio Ceolin


Re: Bluetooth: Mesh: about pending things

Johan Hedberg
 

Hi Vikrant,

On Sat, Sep 29, 2018, vikrant8051 wrote:
Just for curiosity, need list of pending things/issues (if any) in current
Bluetooth Stack to fully satisfy SIG Mesh specification v1.0.

Till when it get entitled as Qualified Bluetooth Mesh stack?
There shouldn't at least be anything techical preventing it. We run the
qualification tests periodically and know that they pass. So any company
that wants to make a qualificaton listing just needs to run the tests,
do the paperwork (provide test evidence, etc) and pay the listing fee.

Johan


Bluetooth: Mesh: about pending things

vikrant8051 <vikrant8051@...>
 

Hi,
Just for curiosity, need list of pending things/issues (if any) in current Bluetooth Stack to fully satisfy SIG Mesh specification v1.0.

Till when it get entitled as Qualified Bluetooth Mesh stack?

Thank You !!



Compilers working on Zephyr

Flavio Ceolin
 

Hi,

Guys I'm trying to have a list of supported compilers on Zephyr, but in
our wiki just mention about 3rd-party compilers but don't mention any
other than GNU ARM compiler.

If you are using a compiler different from our SDK, can you tell me so I
can catalog it. If you're just trying to use other compiler, please tell
me which problems you are facing.

Regards,
Flavio Ceolin


Re: What are the requirements for running coap_server on a board?

Rissanen, Jukka <jukka.rissanen@...>
 

Hi,

in order the upper IP stack to send packets to radio network, there
must be a network interface in the system. All IP network traffic goes
through this network interface. A network interface gets created by
NET_DEVICE_INIT() macro, typically this is located in network device
driver. There needs to be a L2 driver that depends on your network
technology, the name of the L2 is given to NET_DEVICE_INIT(). You can
see existing ethernet driver in drivers/ethernet/eth*.c for some
examples.


Cheers,
Jukka


On Fri, 2018-09-28 at 15:15 +0300, seems.deviant@gmail.com wrote:
Hello,

I'd like to check for radio connectivity between two of my ST B-
L072Z-
LRWAN1 boards.

Each of those boards has a SX1276 LoRa radio transceiver connected
over
SPI1. For the test purposes, I'd like Zephyr coap_server and
coap_client applications use that interface to exchange messages.

The SPI1 is enabled and configured on both boards. I've tried to run
a
coap_server on a board with configured SPI1, but I got error
"join_coap_multicast_group: Could not get te default interface".

Obviously, a default network interface definition is missing from my
board configuration. As far as I understand, a networking interface
is
to be defined and picked up by a particular driver - e.g Bluetooth,
Ethernet, IEEE 802.15.4.

So, How do I define a default networking interface and make it
accept,
say, Ethernet packets?


---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


Re: What are the requirements for running coap_server on a board?

Jukka Rissanen
 

Hi,

in order the upper IP stack to send packets to radio network, there
must be a network interface in the system. All IP network traffic goes
through this network interface. A network interface gets created by
NET_DEVICE_INIT() macro, typically this is located in network device
driver. There needs to be a L2 driver that depends on your network
technology, the name of the L2 is given to NET_DEVICE_INIT(). You can
see existing ethernet driver in drivers/ethernet/eth*.c for some
examples.


Cheers,
Jukka

On Fri, 2018-09-28 at 15:15 +0300, seems.deviant@gmail.com wrote:
Hello,

I'd like to check for radio connectivity between two of my ST B-
L072Z-
LRWAN1 boards.

Each of those boards has a SX1276 LoRa radio transceiver connected
over
SPI1. For the test purposes, I'd like Zephyr coap_server and
coap_client applications use that interface to exchange messages.

The SPI1 is enabled and configured on both boards. I've tried to run
a
coap_server on a board with configured SPI1, but I got error
"join_coap_multicast_group: Could not get te default interface".

Obviously, a default network interface definition is missing from my
board configuration. As far as I understand, a networking interface
is
to be defined and picked up by a particular driver - e.g Bluetooth,
Ethernet, IEEE 802.15.4.

So, How do I define a default networking interface and make it
accept,
say, Ethernet packets?



What are the requirements for running coap_server on a board?

seems.deviant@...
 

Hello,

I'd like to check for radio connectivity between two of my ST B-L072Z-
LRWAN1 boards.

Each of those boards has a SX1276 LoRa radio transceiver connected over
SPI1. For the test purposes, I'd like Zephyr coap_server and
coap_client applications use that interface to exchange messages.

The SPI1 is enabled and configured on both boards. I've tried to run a
coap_server on a board with configured SPI1, but I got error
"join_coap_multicast_group: Could not get te default interface".

Obviously, a default network interface definition is missing from my
board configuration. As far as I understand, a networking interface is
to be defined and picked up by a particular driver - e.g Bluetooth,
Ethernet, IEEE 802.15.4.

So, How do I define a default networking interface and make it accept,
say, Ethernet packets?


Re: MPU fault while testing Bluetooth Mesh Sample demos

vikrant8051 <vikrant8051@...>
 

Hi Vinayak,

No. The issue has solved now.

Regards,
vikrant


On Thu, Sep 27, 2018 at 1:14 PM Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> wrote:
Are you still receiving MPU Fault? I have solved someone's similar problem., and had a question if you are using GATT API and by any chance the control flows through bt_att_req_send function?

-Vinayak



-----Original Message-----
From: <devel@...> on behalf of Jiří Kubias <jiri.kubias@...>
Date: Tuesday, 18 September 2018 at 8:07 AM
To: vikrant8051 <vikrant8051@...>
Cc: Carles Cufi <Carles.Cufi@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

    Hi,
    last night I have discovered that I have messed up variables and I have tried to assign value to constant variable -> that is the reason why I have received the MPU fault.


    Best regards,
    Jiri


    po 17. 9. 2018 v 16:29 odesílatel Jiří Kubias <jiri.kubias@...> napsal:


    Hi,
    In my case the MPU falut was stable. But in your case it looks like some race condition issue.


    Try to reorganise the initialisation or add some delays.


    Regards Jiri




    Dne po 17. 9. 2018 15:39 uživatel Vikrant More <vikrant8051@...> napsal:


    Hi Jiri,
    After replying to your email, I once again started testing thoroughly.
    And yes, once again I got MPU fault.


    Regards,
    Vikrant



    On Mon, Sep 17, 2018 at 6:30 PM vikrant8051 <vikrant8051@...> wrote:


    HI Jiri,
    After latest sync with master, I've not faced MPU FAULT issue
    while testing. But it could be there. With v1.13, it could be suddenly
    pops-up without any reason (as a app developer)



    Thanks for linking your issue with this mailing list. Hope Zephyr

    core developers will resolve it.



    Regards,
    vikrant







    On Mon, Sep 17, 2018 at 12:37 PM Jiří Kubias <jiri.kubias@...> wrote:


    Hi,
    have you found a solution? Few days ago I have reported similar problem with MPU fault but with Atmel (Microchip) SAME70 chip. It is cased by binding DMA.

        dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
    if (!dev_cfg->dev_dma) {
    SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
    return -ENODEV;
    }





    and the console output  is

    ***** MPU FAULT *****
     Data Access Violation
     MMFAR Address: 0x412198
    ***** Hardware exception *****
    Current thread ID = 0x204024b4
    Faulting instruction address = 0x40e376
    Fatal fault in essential thread! Spinning...





    So far I didnt solved the issue, but I didnt had a much time to debug it.


    Best regards,
    Jiri






    2018-09-14 12:33 GMT+02:00 vikrant8051 <vikrant8051@...>:

    Hi Carles,
    -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    >> Did you run addr2line in 0x20001c5c?


    ***** MPU FAULT *****                                                                                                           

      Instruction Access Violation                                                                                                   

    ***** Hardware exception *****                                                                                                   

    Current thread ID = 0x20001884                                                                                                   

    Faulting instruction address = 0x20001c88                                                                                       

    Fatal fault in ISR! Spinning...



    1)

    /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e  /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf
     0x20001c88


    &




    /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line
     -e  /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


    Both returns -> :? ...... with zephyr-SDK


    2)

    I also tried to compile the App using latest gcc-arm-none-eabi-7-2018-q2



    2.1)

    /opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001c88



    o/p -> isr_tables.c:?


    2.2)

    /opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


    o/p -> /home/vikrant/zephyr/kernel/init.c:80

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

    >> Have you tried increasing stack sizes?


    Yes.
    CONFIG_MAIN_STACK_SIZE=512 ....to 1024
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048 ....to 4096


    But still getting MPU Fault in case of Board executing BT Mesh Servers.













    On Fri, Sep 14, 2018 at 3:31 PM Cufi, Carles <Carles.Cufi@...> wrote:


    Hi there,

    Did you run addr2line in 0x20001c5c?
    Have you tried increasing stack sizes?

    Carles

    From:
    devel@... <mailto:devel@...> <devel@...>
    On Behalf Of vikrant8051
    Sent: 14 September 2018 11:48
    To:
    devel@... <mailto:devel@...>;
    users@... <mailto:users@...>
    Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos



    Hi,



    FYI,

    With v1.12.99 I'm mot facing any MPU FAULT issue (while testing for #onoff_level_lighting_vnd_app)


    It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d



    That means something after it has changed the things bcz of that we are getting

    MPU FAULT.



    Thank You !!




    On Wed, Sep 5, 2018 at 10:50 AM vikrant8051 <vikrant8051@...> wrote:


    Hi,

    I'm getting following MPU fault while testing with samples for Bluetooth Mesh . This issue has started after syncing with master branch.



    ***** MPU FAULT *****                                                                                                           

      Instruction Access Violation                                                                                                   

    ***** Hardware exception *****                                                                                                   

    Current thread ID = 0x2000188c                                                                                                   

    Faulting instruction address = 0x20001c5c                                                                                       

    Fatal fault in ISR! Spinning...





    Thank You !!



























    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================


















    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================


Re: MPU fault while testing Bluetooth Mesh Sample demos

Jiří Kubias <jiri.kubias@...>
 

Hi,
no. Each time I received MPU fault it was my mistake. I have made two mistakes: Write into const value (this is really not working) and i called k_free from ISR (I didnt realize that DMA callback is called from DMA ISR). After this I have no more MPU fault. 

Im not using BLE.

Regards, 
Jiri 

čt 27. 9. 2018 v 9:44 odesílatel Chettimada, Vinayak Kariappa <vinayak.kariappa.chettimada@...> napsal:

Are you still receiving MPU Fault? I have solved someone's similar problem., and had a question if you are using GATT API and by any chance the control flows through bt_att_req_send function?

-Vinayak



-----Original Message-----
From: <devel@...> on behalf of Jiří Kubias <jiri.kubias@...>
Date: Tuesday, 18 September 2018 at 8:07 AM
To: vikrant8051 <vikrant8051@...>
Cc: Carles Cufi <Carles.Cufi@...>, "devel@..." <devel@...>, "users@..." <users@...>
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

    Hi,
    last night I have discovered that I have messed up variables and I have tried to assign value to constant variable -> that is the reason why I have received the MPU fault.


    Best regards,
    Jiri


    po 17. 9. 2018 v 16:29 odesílatel Jiří Kubias <jiri.kubias@...> napsal:


    Hi,
    In my case the MPU falut was stable. But in your case it looks like some race condition issue.


    Try to reorganise the initialisation or add some delays.


    Regards Jiri




    Dne po 17. 9. 2018 15:39 uživatel Vikrant More <vikrant8051@...> napsal:


    Hi Jiri,
    After replying to your email, I once again started testing thoroughly.
    And yes, once again I got MPU fault.


    Regards,
    Vikrant



    On Mon, Sep 17, 2018 at 6:30 PM vikrant8051 <vikrant8051@...> wrote:


    HI Jiri,
    After latest sync with master, I've not faced MPU FAULT issue
    while testing. But it could be there. With v1.13, it could be suddenly
    pops-up without any reason (as a app developer)



    Thanks for linking your issue with this mailing list. Hope Zephyr

    core developers will resolve it.



    Regards,
    vikrant







    On Mon, Sep 17, 2018 at 12:37 PM Jiří Kubias <jiri.kubias@...> wrote:


    Hi,
    have you found a solution? Few days ago I have reported similar problem with MPU fault but with Atmel (Microchip) SAME70 chip. It is cased by binding DMA.

        dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
    if (!dev_cfg->dev_dma) {
    SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
    return -ENODEV;
    }





    and the console output  is

    ***** MPU FAULT *****
     Data Access Violation
     MMFAR Address: 0x412198
    ***** Hardware exception *****
    Current thread ID = 0x204024b4
    Faulting instruction address = 0x40e376
    Fatal fault in essential thread! Spinning...





    So far I didnt solved the issue, but I didnt had a much time to debug it.


    Best regards,
    Jiri






    2018-09-14 12:33 GMT+02:00 vikrant8051 <vikrant8051@...>:

    Hi Carles,
    -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    >> Did you run addr2line in 0x20001c5c?


    ***** MPU FAULT *****                                                                                                           

      Instruction Access Violation                                                                                                   

    ***** Hardware exception *****                                                                                                   

    Current thread ID = 0x20001884                                                                                                   

    Faulting instruction address = 0x20001c88                                                                                       

    Fatal fault in ISR! Spinning...



    1)

    /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e  /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf
     0x20001c88


    &




    /opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line
     -e  /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


    Both returns -> :? ...... with zephyr-SDK


    2)

    I also tried to compile the App using latest gcc-arm-none-eabi-7-2018-q2



    2.1)

    /opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001c88



    o/p -> isr_tables.c:?


    2.2)

    /opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


    o/p -> /home/vikrant/zephyr/kernel/init.c:80

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

    >> Have you tried increasing stack sizes?


    Yes.
    CONFIG_MAIN_STACK_SIZE=512 ....to 1024
    CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048 ....to 4096


    But still getting MPU Fault in case of Board executing BT Mesh Servers.













    On Fri, Sep 14, 2018 at 3:31 PM Cufi, Carles <Carles.Cufi@...> wrote:


    Hi there,

    Did you run addr2line in 0x20001c5c?
    Have you tried increasing stack sizes?

    Carles

    From:
    devel@... <mailto:devel@...> <devel@...>
    On Behalf Of vikrant8051
    Sent: 14 September 2018 11:48
    To:
    devel@... <mailto:devel@...>;
    users@... <mailto:users@...>
    Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos



    Hi,



    FYI,

    With v1.12.99 I'm mot facing any MPU FAULT issue (while testing for #onoff_level_lighting_vnd_app)


    It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d



    That means something after it has changed the things bcz of that we are getting

    MPU FAULT.



    Thank You !!




    On Wed, Sep 5, 2018 at 10:50 AM vikrant8051 <vikrant8051@...> wrote:


    Hi,

    I'm getting following MPU fault while testing with samples for Bluetooth Mesh . This issue has started after syncing with master branch.



    ***** MPU FAULT *****                                                                                                           

      Instruction Access Violation                                                                                                   

    ***** Hardware exception *****                                                                                                   

    Current thread ID = 0x2000188c                                                                                                   

    Faulting instruction address = 0x20001c5c                                                                                       

    Fatal fault in ISR! Spinning...





    Thank You !!



























    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================


















    --
    ===================================================
    Ing. Jiri Kubias

    e-mail: jiri.kubias@...
    mobile: 775 593 956
    ===================================================



--
===================================================
Ing. Jiri Kubias
 
e-mail: jiri.kubias@...
mobile: 775 593 956
===================================================


Re: MPU fault while testing Bluetooth Mesh Sample demos

Chettimada, Vinayak Kariappa
 

Are you still receiving MPU Fault? I have solved someone's similar problem., and had a question if you are using GATT API and by any chance the control flows through bt_att_req_send function?

-Vinayak

-----Original Message-----
From: <devel@lists.zephyrproject.org> on behalf of Jiří Kubias <jiri.kubias@gmail.com>
Date: Tuesday, 18 September 2018 at 8:07 AM
To: vikrant8051 <vikrant8051@gmail.com>
Cc: Carles Cufi <Carles.Cufi@nordicsemi.no>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>, "users@lists.zephyrproject.org" <users@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos

Hi,
last night I have discovered that I have messed up variables and I have tried to assign value to constant variable -> that is the reason why I have received the MPU fault.


Best regards,
Jiri


po 17. 9. 2018 v 16:29 odesílatel Jiří Kubias <jiri.kubias@gmail.com> napsal:


Hi,
In my case the MPU falut was stable. But in your case it looks like some race condition issue.


Try to reorganise the initialisation or add some delays.


Regards Jiri




Dne po 17. 9. 2018 15:39 uživatel Vikrant More <vikrant8051@gmail.com> napsal:


Hi Jiri,
After replying to your email, I once again started testing thoroughly.
And yes, once again I got MPU fault.


Regards,
Vikrant



On Mon, Sep 17, 2018 at 6:30 PM vikrant8051 <vikrant8051@gmail.com> wrote:


HI Jiri,
After latest sync with master, I've not faced MPU FAULT issue
while testing. But it could be there. With v1.13, it could be suddenly
pops-up without any reason (as a app developer)



Thanks for linking your issue with this mailing list. Hope Zephyr

core developers will resolve it.



Regards,
vikrant







On Mon, Sep 17, 2018 at 12:37 PM Jiří Kubias <jiri.kubias@gmail.com> wrote:


Hi,
have you found a solution? Few days ago I have reported similar problem with MPU fault but with Atmel (Microchip) SAME70 chip. It is cased by binding DMA.

dev_cfg->dev_dma = device_get_binding(CONFIG_SPI_SAM_DMA_NAME);
if (!dev_cfg->dev_dma) {
SYS_LOG_ERR("%s device not found", CONFIG_SPI_SAM_DMA_NAME);
return -ENODEV;
}





and the console output is

***** MPU FAULT *****
Data Access Violation
MMFAR Address: 0x412198
***** Hardware exception *****
Current thread ID = 0x204024b4
Faulting instruction address = 0x40e376
Fatal fault in essential thread! Spinning...





So far I didnt solved the issue, but I didnt had a much time to debug it.


Best regards,
Jiri






2018-09-14 12:33 GMT+02:00 vikrant8051 <vikrant8051@gmail.com>:

Hi Carles,
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>> Did you run addr2line in 0x20001c5c?


***** MPU FAULT *****

Instruction Access Violation

***** Hardware exception *****

Current thread ID = 0x20001884

Faulting instruction address = 0x20001c88

Fatal fault in ISR! Spinning...



1)

/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf
0x20001c88


&




/opt/zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-zephyr-eabi/arm-zephyr-eabi-addr2line
-e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


Both returns -> :? ...... with zephyr-SDK


2)

I also tried to compile the App using latest gcc-arm-none-eabi-7-2018-q2



2.1)

/opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001c88



o/p -> isr_tables.c:?


2.2)

/opt/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-addr2line -e /home/vikrant/zephyr/samples/boards/nrf52/mesh/onoff_level_lighting_vnd_app/build/zephyr/zephyr.elf 0x20001884


o/p -> /home/vikrant/zephyr/kernel/init.c:80

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

>> Have you tried increasing stack sizes?


Yes.
CONFIG_MAIN_STACK_SIZE=512 ....to 1024
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=2048 ....to 4096


But still getting MPU Fault in case of Board executing BT Mesh Servers.













On Fri, Sep 14, 2018 at 3:31 PM Cufi, Carles <Carles.Cufi@nordicsemi.no> wrote:


Hi there,

Did you run addr2line in 0x20001c5c?
Have you tried increasing stack sizes?

Carles

From:
devel@lists.zephyrproject.org <mailto:devel@lists.zephyrproject.org> <devel@lists.zephyrproject.org>
On Behalf Of vikrant8051
Sent: 14 September 2018 11:48
To:
devel@lists.zephyrproject.org <mailto:devel@lists.zephyrproject.org>;
users@lists.zephyrproject.org <mailto:users@lists.zephyrproject.org>
Subject: Re: [Zephyr-devel] MPU fault while testing Bluetooth Mesh Sample demos



Hi,



FYI,

With v1.12.99 I'm mot facing any MPU FAULT issue (while testing for #onoff_level_lighting_vnd_app)


It has last commit -> ba6763a187a347cfc825a2bece78e7d1ef28772d



That means something after it has changed the things bcz of that we are getting

MPU FAULT.



Thank You !!




On Wed, Sep 5, 2018 at 10:50 AM vikrant8051 <vikrant8051@gmail.com> wrote:


Hi,

I'm getting following MPU fault while testing with samples for Bluetooth Mesh . This issue has started after syncing with master branch.



***** MPU FAULT *****

Instruction Access Violation

***** Hardware exception *****

Current thread ID = 0x2000188c

Faulting instruction address = 0x20001c5c

Fatal fault in ISR! Spinning...





Thank You !!



























--
===================================================
Ing. Jiri Kubias

e-mail: jiri.kubias@gmail.com
mobile: 775 593 956
===================================================


















--
===================================================
Ing. Jiri Kubias

e-mail: jiri.kubias@gmail.com
mobile: 775 593 956
===================================================


Re: BLE stack using PPI channels #ble #nrf52832

robert.konc@...
 

Hi Charles

We need 6 PPI channels to drive BLDC motor.
For now I'm modify radio_nrf5_ppi.h. So I could work.
File si also attached.
In begginig of file is  #define CONFIG_BT_NRF52X_RADIO_EVENT_TIMER which enable to use predefine PPI's.
 


Python Conference and devsprint in India

Sathishkumar Duraisamy <bewithsathish@...>
 

Hi All,


I new to zephyr. Last few weeks I have been experiment with zephyr and also the west.


I have some proposal, there is python conference going to take place in India on Oct 6,7 with devsprint on Oct 8, 9. Here is the link for devsprint https://in.pycon.org/cfp/devsprint-2018/proposals/. Shall we use devsprint to bring some contribution to west?



Thanks and Regards,
Sathishkumar D


Re: BLE stack using PPI channels #ble #nrf52832

Chettimada, Vinayak Kariappa
 

Hi,

Only 5 of the pre-programmed PPI can be reused in Zephyr's BLE implementation. But the task to refactor the controller is not simple (i.e. not doable in a day or two).

In upstream Zephyr, PPI's 16,17, 18 and 19 are free for nRF52832. And additionally, 14 and 15 are free if PA/LNA is not enabled.

Regards,
Vinayak

-----Original Message-----
From: "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@nordicsemi.no>
Date: Wednesday, 26 September 2018 at 1:02 PM
To: Carles Cufi <Carles.Cufi@nordicsemi.no>, "Bøe, Sebastian" <Sebastian.Boe@nordicsemi.no>, "robert.konc@controlmatik.eu" <robert.konc@controlmatik.eu>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Cc: Andrzej Głąbek <Andrzej.Glabek@nordicsemi.no>
Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Hi,

The pre-programmed PPI are very specific to Nordic's in-house stack implementation needs. Some of them coincidentally can be re-used in Zephyr implementation.
I will try to send a PR by EOD, if its doing in few minutes. Else, assume that it’s a bit more work.

Regards,
Vinayak

-----Original Message-----
From: Carles Cufi <Carles.Cufi@nordicsemi.no>
Date: Wednesday, 26 September 2018 at 12:53 PM
To: "Bøe, Sebastian" <Sebastian.Boe@nordicsemi.no>, "robert.konc@controlmatik.eu" <robert.konc@controlmatik.eu>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Cc: Andrzej Głąbek <Andrzej.Glabek@nordicsemi.no>, "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@nordicsemi.no>
Subject: RE: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Hi Sebastian, Robert,

Sebastian, thanks for pointing out the existing issue.
Robert, would you please comment on that issue stating the needs of your application so we can evaluate how best to fix this and we can also include you in upcoming Pull Request reviews so you can make sure we've addressed it in a way compatible with your requirements?

Andrzej, Vinayak: We should revisit this as soon as possible. Is DTS an option here? I assume not since this is an nRF-specific hardware resource.

Carles

> -----Original Message-----
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
> Behalf Of Sebastian Boe
> Sent: 26 September 2018 12:36
> To: robert.konc@controlmatik.eu; devel@lists.zephyrproject.org
> Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> Good question, there exists an issue that can be used for this
> discussion:
>
> https://github.com/zephyrproject-rtos/zephyr/issues/7092
>
> ________________________________________
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
> behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
> Sent: Wednesday, September 26, 2018 12:33:18 PM
> To: devel@lists.zephyrproject.org
> Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> In my application I was try to use 6 PPI channels. And I discovered that
> almost all channels is used by BLE stack.
> NRF52 chip have dedicated PPI [20:31] channels for radio. Why this
> challens was not used by BLE stack.
> Is three any posibilities to change this?
>
> Thanks in advance!
>
> Br,
> Robert
>
>
>


Re: BLE stack using PPI channels #ble #nrf52832

Chettimada, Vinayak Kariappa
 

Hi,

The pre-programmed PPI are very specific to Nordic's in-house stack implementation needs. Some of them coincidentally can be re-used in Zephyr implementation.
I will try to send a PR by EOD, if its doing in few minutes. Else, assume that it’s a bit more work.

Regards,
Vinayak

-----Original Message-----
From: Carles Cufi <Carles.Cufi@nordicsemi.no>
Date: Wednesday, 26 September 2018 at 12:53 PM
To: "Bøe, Sebastian" <Sebastian.Boe@nordicsemi.no>, "robert.konc@controlmatik.eu" <robert.konc@controlmatik.eu>, "devel@lists.zephyrproject.org" <devel@lists.zephyrproject.org>
Cc: Andrzej Głąbek <Andrzej.Glabek@nordicsemi.no>, "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@nordicsemi.no>
Subject: RE: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Hi Sebastian, Robert,

Sebastian, thanks for pointing out the existing issue.
Robert, would you please comment on that issue stating the needs of your application so we can evaluate how best to fix this and we can also include you in upcoming Pull Request reviews so you can make sure we've addressed it in a way compatible with your requirements?

Andrzej, Vinayak: We should revisit this as soon as possible. Is DTS an option here? I assume not since this is an nRF-specific hardware resource.

Carles

> -----Original Message-----
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
> Behalf Of Sebastian Boe
> Sent: 26 September 2018 12:36
> To: robert.konc@controlmatik.eu; devel@lists.zephyrproject.org
> Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> Good question, there exists an issue that can be used for this
> discussion:
>
> https://github.com/zephyrproject-rtos/zephyr/issues/7092
>
> ________________________________________
> From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
> behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
> Sent: Wednesday, September 26, 2018 12:33:18 PM
> To: devel@lists.zephyrproject.org
> Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832
>
> In my application I was try to use 6 PPI channels. And I discovered that
> almost all channels is used by BLE stack.
> NRF52 chip have dedicated PPI [20:31] channels for radio. Why this
> challens was not used by BLE stack.
> Is three any posibilities to change this?
>
> Thanks in advance!
>
> Br,
> Robert
>
>
>


Re: BLE stack using PPI channels #ble #nrf52832

Carles Cufi
 

Hi Sebastian, Robert,

Sebastian, thanks for pointing out the existing issue.
Robert, would you please comment on that issue stating the needs of your application so we can evaluate how best to fix this and we can also include you in upcoming Pull Request reviews so you can make sure we've addressed it in a way compatible with your requirements?

Andrzej, Vinayak: We should revisit this as soon as possible. Is DTS an option here? I assume not since this is an nRF-specific hardware resource.

Carles

-----Original Message-----
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> On
Behalf Of Sebastian Boe
Sent: 26 September 2018 12:36
To: robert.konc@controlmatik.eu; devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

Good question, there exists an issue that can be used for this
discussion:

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

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on
behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
Sent: Wednesday, September 26, 2018 12:33:18 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

In my application I was try to use 6 PPI channels. And I discovered that
almost all channels is used by BLE stack.
NRF52 chip have dedicated PPI [20:31] channels for radio. Why this
challens was not used by BLE stack.
Is three any posibilities to change this?

Thanks in advance!

Br,
Robert



Re: BLE stack using PPI channels #ble #nrf52832

Sebastian Boe
 

Good question, there exists an issue that can be used for this discussion:

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

________________________________________
From: devel@lists.zephyrproject.org <devel@lists.zephyrproject.org> on behalf of robert.konc@controlmatik.eu <robert.konc@controlmatik.eu>
Sent: Wednesday, September 26, 2018 12:33:18 PM
To: devel@lists.zephyrproject.org
Subject: [Zephyr-devel] BLE stack using PPI channels #ble #nrf52832

In my application I was try to use 6 PPI channels. And I discovered that almost all channels is used by BLE stack.
NRF52 chip have dedicated PPI [20:31] channels for radio. Why this challens was not used by BLE stack.
Is three any posibilities to change this?

Thanks in advance!

Br,
Robert


BLE stack using PPI channels #ble #nrf52832

robert.konc@...
 

In my application I was try to use 6 PPI channels. And I discovered that almost all channels is used by BLE stack.
NRF52 chip have dedicated PPI [20:31] channels for radio. Why this challens was not used by BLE stack.
Is three any posibilities to change this?

Thanks in advance!

Br,
Robert

3021 - 3040 of 8199