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:
|
|
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@... <devel@...> on behalf of Flavio Ceolin <flavio.ceolin@...> Sent: Saturday, September 29, 2018 12:01:04 AM To: zephyr-devel@... 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
Hi Vikrant,
On Sat, Sep 29, 2018, vikrant8051 wrote: Just for curiosity, need list of pending things/issues (if any) in currentThere 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@... wrote: Hello,--------------------------------------------------------------------- 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,
toggle quoted messageShow quoted text
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@... wrote:
Hello,
|
|
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?
|
|
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? --
=================================================== 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?
toggle quoted messageShow quoted text
-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 ===================================================
|
|
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
|
|
Chettimada, Vinayak Kariappa
Hi,
toggle quoted messageShow quoted text
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@...> Date: Wednesday, 26 September 2018 at 1:02 PM To: Carles Cufi <Carles.Cufi@...>, "Bøe, Sebastian" <Sebastian.Boe@...>, "robert.konc@..." <robert.konc@...>, "devel@..." <devel@...> Cc: Andrzej Głąbek <Andrzej.Glabek@...> 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@...> Date: Wednesday, 26 September 2018 at 12:53 PM To: "Bøe, Sebastian" <Sebastian.Boe@...>, "robert.konc@..." <robert.konc@...>, "devel@..." <devel@...> Cc: Andrzej Głąbek <Andrzej.Glabek@...>, "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...> 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@... <devel@...> On > Behalf Of Sebastian Boe > Sent: 26 September 2018 12:36 > To: robert.konc@...; devel@... > 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@... <devel@...> on > behalf of robert.konc@... <robert.konc@...> > Sent: Wednesday, September 26, 2018 12:33:18 PM > To: devel@... > 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 > > >
|
|
Chettimada, Vinayak Kariappa
Hi,
toggle quoted messageShow quoted text
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@...> Date: Wednesday, 26 September 2018 at 12:53 PM To: "Bøe, Sebastian" <Sebastian.Boe@...>, "robert.konc@..." <robert.konc@...>, "devel@..." <devel@...> Cc: Andrzej Głąbek <Andrzej.Glabek@...>, "Chettimada, Vinayak Kariappa" <vinayak.kariappa.chettimada@...> 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@... <devel@...> On > Behalf Of Sebastian Boe > Sent: 26 September 2018 12:36 > To: robert.konc@...; devel@... > 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@... <devel@...> on > behalf of robert.konc@... <robert.konc@...> > Sent: Wednesday, September 26, 2018 12:33:18 PM > To: devel@... > 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 > > >
|
|
Carles Cufi
Hi Sebastian, Robert,
toggle quoted messageShow quoted text
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-----
|
|
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@... <devel@...> on behalf of robert.konc@... <robert.konc@...> Sent: Wednesday, September 26, 2018 12:33:18 PM To: devel@... 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
|
|
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
|
|